Bug 703058 – Make ebuilds for installed packages available for reinstallation

• Product: Portage Development
• Status: RESOLVED DUPLICATE

[Description skaumo 2019-12-16 02:58:50 UTC]

Ebuilds that belong to currently installed packages should be kept available for reinstalls


Any emerge --sync can delete ebuilds of currently installed packages.

However, there are several reasons (e.g.: RDEPEND) that require emerge to reinstall existing dependencies (maybe with a different USE flag), but the fact the corresponding ebuilds are gone, can make Portage unable to bring the system back to a consistent state. See steps below.




Reproducible: Always

Steps to Reproduce:
1) An apparently harmless patch update for package1 is performed:
   package1-r1 is updated to package1-r2


2) The maintainer believes it all works OK and deletes the ebuild for package1-r1 from the portage tree


3) So, at the following emaint sync, package1-r1.ebuild becomes unavailable and can no longer be installed/reinstalled.


4) Turns out the updated package1-r2 fails on my system, so I can't install it either.


5) Meantime, trying to install package2 triggers a rebuild of package1, whichever version, via RDEPEND, but since package1-r1 is lost and package1-r2 is broken, we are stuck.


6) I try hard-masking package1-r2 to make sure Portage doesn't even attempt to emerge it, as both package2 and myself are happy with the current version of package1-r1


Actual Results:  
package2 can not be installed, because it depends on a rebuild of package1, which can no longer be performed (emerge reports it as masked or unavailable)

Expected Results:  
Portage should make an effort to keep and reuse package1-r1.ebuild and seamlessly reinstall it along with package2


Users should not be expected to resort on manual workarounds like finding and copying the missing ebuilds from /var/db/pkg maybe into their local ebuild repositories, at least not as long as the required packages are already installed.



For packages to be currently installed is really the key point here




This is causing lots of problems in updating stale systems which haven't been updated for some time, since RDEPEND.


Portage could brilliantly deal with many very complex upgrade situations, but the fact that ebuilds for currently installed packages are unavailable, cause it to fail miserably, instead.




The proposal here is either of the following:

  - emerge --sync should move deleted ebuilds to some local, temporary overlay so long as the corresponding packages are installed

  - emerge --sync should not remove ebuilds for currently installed packages (maybe not the best thing to do)

  - emerge <atom> should automatically find and reuse ebuilds for dependencies which are already installed, even if they have been removed from the portage (or overlay) tree (maybe just look them up in /var/db/pkg?)





The benefits would be significant in all the following cases:

  - installing/updating packages whose dependencies could be only resolved from /var/db/pkg

  - updating old systems, which at the moment are notoriously difficult to do either partial or full updates on.

[Comment 1 Zac Medico 2019-12-16 04:21:22 UTC]

We can extend the snapshot behavior of sync-rcu to preserve repository snapshots containing the ebuilds for your installed packages.

[Comment 2 Fabian Groffen 2019-12-16 07:36:14 UTC]

The vdb contains a copy of the ebuild, the only missing thing are the eclasses used.  Would environment.bz2 be able to reprocess a package with different ebuilds?

[Comment 3 Zac Medico 2019-12-16 09:10:01 UTC]

(In reply to Fabian Groffen from comment #2)
> The vdb contains a copy of the ebuild, the only missing thing are the
> eclasses used.  Would environment.bz2 be able to reprocess a package with
> different ebuilds?

FILESDIR is also missing, so vdb is practically unusable.

[Comment 4 Zac Medico 2021-01-05 18:08:00 UTC]

*** Bug 763888 has been marked as a duplicate of this bug. ***

[Comment 5 Sam James 2022-07-28 05:04:42 UTC]

The more I think about this, the more I think this might be a good idea, even if not ideal, because of how often we see people with subslot conflicts b/c they have some package installed which can't be rebuilt (b/c maybe missing package.accept_keywords entry for a newer version)

It also makes it very hard to just mask a newer version of something and stay on it.

[Comment 6 Sam James 2022-07-28 05:16:05 UTC]

*** This bug has been marked as a duplicate of bug 303403 ***