Disclaimer: I did "ALL sys-apps/portage" and reviewed the proposed possible duplicate bugs before going ahead with this entry. I also went ahead with htis entry because I have a proposed 'rule' which I think will help. Of course, I'm not a programmer and this may not be helpful after all. I apologise if this is a duplicate entry. Under certain conditions, use of "emerge --depclean" will propose slotted versions of packages for deletion which should not actually deleted. While the user has final responsibility to review the proposed removal list, it isn't always clear when the some of the items should be overridden. Consider: # eix sys-libs/db [I] sys-libs/db Available versions: (1) 1.85-r3 (3) 3.2.9_p2 (4.2) 4.2.52_p5-r1 (4.3) 4.3.29_p1-r1 (4.4) (~)4.4.20_p4-r1 (4.5) 4.5.20_p2-r1 (4.6) 4.6.21_p4 (4.7) 4.7.25_p4 (4.8) 4.8.30-r2{tbz2} (5.1) (~)5.1.29-r1 (5.3) 5.3.28-r2{tbz2} (~)5.3.28-r3{tbz2} (6.0) (~)6.0.35{tbz2} (~)6.0.35-r1{tbz2} (6.1) [M](~)6.1.29 [M](~)6.1.29-r1 (6.2) [M](~)6.2.23 [M](~)6.2.23-r1 [M](~)6.2.32 [M](~)6.2.32-r1 ... Installed versions: 4.8.30-r2(4.8){tbz2}(09:46:56 AM 01/06/2018) ... 5.3.28-r3(5.3){tbz2}(10:39:40 AM 03/31/2018) ... 6.0.35-r1(6.0){tbz2}(09:41:56 AM 01/06/2018) ... # equery d sys-libs/db * These packages depend on sys-libs/db: dev-lang/perl-5.26.1-r2 (berkdb ? sys-libs/db) dev-lang/php-7.2.4 (berkdb ? sys-libs/db:5.3) (berkdb ? sys-libs/db:5.1) (berkdb ? sys-libs/db:4.8) (berkdb ? sys-libs/db:4.7) (berkdb ? sys-libs/db:4.6) (berkdb ? sys-libs/db:4.5) dev-lang/python-2.7.14-r1 (berkdb ? sys-libs/db:5.3) ... # emerge -p --depclean ... sys-libs/db selected: 5.3.28-r3 protected: none omitted: 4.8.30-r2 6.0.35-r1 ... In this case, sys-libs/db-5.3.28-r3 is being proposed for removal. Under normal, "end user" circumstances, I'd let this one go. If the removal is permitted, then dev-lang/php-7.* will appear in @preserved-rebuild and never go away. What's happening is that --depclean considers dev-lang/php fulfilled with db:4.8 and db:6.0 is an installed later version, then db:5.3 is a candidate for removal. --depclean should not consider the highest permitted version of a dependent package for removal ever. i.e. db:5.3 is the highest dependent version for dev-lang/php-7.* and therefore should not be considered for removal. As an added possible wrinkle, this condition may apply only when the parent package involved is multi-slotted. I have no way of checking that. I did have dev-lang/php-7.* in @preserved-rebuild for several months before I figured this out. I accumulated a lot of dead packages to remove in the meantime. ... >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. Packages installed: 2185 Packages in world: 397 Packages in system: 43 Required packages: 2017 Number to remove: 168
Note that once db:5.3 was removed, re-emerging php-7.* (through @preserved-rebuild) never picked up dg:5.3 as a dependency to also be emerged. I had to manually emerge db:5.3. This works correctly as expected since db:6.0 supercedes db:5.3 and db:4.8 already satisfied php-7.* emerge --onshot =sys-libs/db-5.3.28-r3
Generally, we solve this kind of problem by using a slot-operator dependency. For example, dev-lang/php could have a dependency like this: COMMON_DEPEND="berkdb? ( <sys-libs/db-5.4:= >=sys-libs/db-4.5:= )" Then the dependencies of installed dev-lang/php instance would be recorded as follows when it is built against sys-libs/db-5.3: <sys-libs/db-5.4:5.3/5.3= >=sys-libs/db-4.5:5.3/5.3= This would ensure that emerge --depclean would keep sys-libs/db-5.3.28-r3 installed. In bug 489458, comment #15 there's a proposed alternative way to express this kind of thing with "||= ( sys-libs/db:5.3 ... sys-libs/db:4.5 )".