Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 652138 - sys-apps/portage --depclean can incorrectly mark slotted packages for removal
Summary: sys-apps/portage --depclean can incorrectly mark slotted packages for removal
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-01 14:06 UTC by Guy
Modified: 2018-04-02 15:40 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guy 2018-04-01 14:06:49 UTC
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
Comment 1 Guy 2018-04-01 14:16:00 UTC
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
Comment 2 Zac Medico gentoo-dev 2018-04-02 15:40:09 UTC
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 )".