Revert installation fails due to missing source bundles about p2

[merks]

@akurtakov @jonahgraham

Note that not having rollback support can be noticeable.

[merks]

Those are no longer in the composite, e.g.,

Recall the discussion on cross projects about the release train composite having multiple versions of bundles and the reason for that being support for rollback?

https://www.eclipse.org/lists/cross-project-issues-dev/msg19228.html

Also, there was recently a discussion to reduce the number of repos in the I build composite to 2 so that has an impact on rollback support as well. @sravanlakkimsetti FYI

So this is not a problem that can be fixed by p2. (Installing with Oomph with it's shared bundle pool would likely not have this problem because the artifacts would remain in the pool until you manually garbage collected them.)

[sravanlakkimsetti]

With 4 repos in I-build repo also will not be able to help here.
@vogella Can you try adding https://download.eclipse.org/eclipse/updates/4.25-I-builds/I20220620-1050 to your repo list and try rollback. this might help

[merks]

Yes, of course at some point the builds are too old. And of course few "real end users" are updating to nightly builds or to SimRel milestone builds so very few are likely impacted but fewer builds in a composite...

[vogella]

So the issue is only that the temp repo is gone? No worries in this case.... I can just download an older version. I agree that having 4 version does not solve this problem.

[merks]

Yes, if the bundles needed for the revert are no longer in the installation's artifact pool (which is generally garbage collected eagerly on startup) and no longer in any available repository, then you will get an error like this.

[jonahgraham]

So this is not a problem that can be fixed by p2.

Not that I am advocating spending the time/effort on this. But it could be fixed on p2 if p2 kept track where it installed from, so when doing the rollback it would know where to find them.

However I would argue (fruitlessly, because again I am not advocating for a change because I don't think it is worth it) that if p2 has a rollback available to users it should not garbage collect those items.

But anyway, I am nowhere near enough knowledgeable about p2 to know if what I said is even correct.

---

On the 2022-09 M2 I have this in my endgame plan:

• In 2022-09 stop making p2 repos composites of all milestones - see https://wiki.eclipse.org/Planning_Council/2022-06-01
  • Test rollback from M2 to M1, and document what it takes to work (best guess is just manually adding in p2 repos)

[merks]

Indeed, in general such a problem cannot be fixed other than by not ever garbage collecting. Update sites can and do disappear. E.g., EMF's nightly build composite has at most 5 sites and one site will be deleted every time there is a new nightly build. (Note that the installer uses a shared bundle pool and it does no automatic garbage collection, so I believe that already solves this problem.)

If at least p2 didn't immediately garbage collect on startup, one could roll back right after installing an update after noticing that it works poorly...

In terms of endgame plans, I think it's much more important that a user updating from 2022-06 to 2022-09 should be able to rollback than someone updating from M1 to M2 should be able to rollback, given that the former involves millions of users while the latter is perhaps a few hundred people. I expect the former works fine while the latter is likely problematic.