+++ This bug was initially created as a clone of Bug #558856 +++ the slotmove section states: The second form instructs the package manager that any currently installed package version matching package dependency specification spec whose SLOT is set to slot1 should have it updated to slot2. in the ncurses example, it has: slotmove ~sys-libs/ncurses-6.0 5 0 package managers (at least portage) will update the installed sys-libs/ncurses from SLOT=5 to SLOT=0, but it will not update any packages that depend on sys-libs/ncurses with a versioned value. so when sys-devel/bc does: >=sys-libs/ncurses-5.2:= it will be recorded as: >=sys-libs/ncurses-5.2:5/6= but the slot will not change from ":5" to ":0". however if the slotmove is written as: slotmove sys-libs/ncurses 5 0 it will perform the update. nowhere does the spec permit or discuss these limitations. versioned support should simply be dropped since it has no real world value and is needlessly dangerous. if another package depends on the package with a slotmove, then it's left broken.
It would be easier to deprecate updates entirely. They're painfully fragile.
Alternatively, we do the hard work and make portage actually map slot deps with a <spec> properly in the *DEPEND of all vdb packages, on a slotmove.
(In reply to Ian Stakenvicius from comment #2) > Alternatively, we do the hard work and make portage actually map slot deps > with a <spec> properly in the *DEPEND of all vdb packages, on a slotmove. But you can't. The idea fundamentally doesn't even make sense. What if a spec matches a range of things, some of which are being moved, and some of which aren't?
(In reply to Ciaran McCreesh from comment #3) > (In reply to Ian Stakenvicius from comment #2) > > Alternatively, we do the hard work and make portage actually map slot deps > > with a <spec> properly in the *DEPEND of all vdb packages, on a slotmove. > > But you can't. The idea fundamentally doesn't even make sense. What if a > spec matches a range of things, some of which are being moved, and some of > which aren't? By definition that can't happen. The range specified in <spec> specifies what is moved. Everything that matches that range gets moved. Something cannot match that range and not be moved. updates/* is stateless and lasts forever, so even if something isn't in the tree yet, as soon as it's added if <spec> matches then it most be moved. If it's already moved, then <spec> (which in the case of slotmove will include the oldslot value) won't match.
(In reply to Ian Stakenvicius from comment #4) > (In reply to Ciaran McCreesh from comment #3) > > (In reply to Ian Stakenvicius from comment #2) > > > Alternatively, we do the hard work and make portage actually map slot deps > > > with a <spec> properly in the *DEPEND of all vdb packages, on a slotmove. > > > > But you can't. The idea fundamentally doesn't even make sense. What if a > > spec matches a range of things, some of which are being moved, and some of > > which aren't? > > By definition that can't happen. The range specified in <spec> specifies > what is moved. Everything that matches that range gets moved. Something > cannot match that range and not be moved. > > updates/* is stateless and lasts forever, so even if something isn't in the > tree yet, as soon as it's added if <spec> matches then it most .. err, must .. > be moved. > > If it's already moved, then <spec> (which in the case of slotmove will > include the oldslot value ..ie the 2nd argument... > ) won't match. to expand, this does mean in order to do it right all atoms matching <spec> need to be found and then the *DEPEND of all packages likely need to be evaluated against that list of atoms. I don't know if this means updates/ will need to be evaluated more often or not, but it's possible that it will.
(In reply to Ian Stakenvicius from comment #4) > (In reply to Ciaran McCreesh from comment #3) > > (In reply to Ian Stakenvicius from comment #2) > > > Alternatively, we do the hard work and make portage actually map slot deps > > > with a <spec> properly in the *DEPEND of all vdb packages, on a slotmove. > > > > But you can't. The idea fundamentally doesn't even make sense. What if a > > spec matches a range of things, some of which are being moved, and some of > > which aren't? > > By definition that can't happen. The range specified in <spec> specifies > what is moved. Everything that matches that range gets moved. Something > cannot match that range and not be moved. But a dependency in a package can be broad enough that it matches some things that get moved, and some that don't. What happens then?
(In reply to Ian Stakenvicius from comment #4) > By definition that can't happen. The range specified in <spec> specifies > what is moved. Everything that matches that range gets moved. Something > cannot match that range and not be moved. Simple example: - cat/foo-1 and cat/foo-2 both have SLOT="0" - cat/bar has RDEPEND="cat/foo:0" Now foo-2 is updated to SLOT=2 and a "slotmove =cat/foo-2 0 2" is done. Do you update the dependency of the installed cat/bar?
OK now I see where the language in PMS itself should likely be made more specific, since there are going to be choices here we will need to make in the implementation for the few cases where slot-move is updating *DEPEND atoms when there is no package currently installed to satisfy it (ie, the unused portion of ||() an dep, or possibly something useflag-disabled?). If there is something installed that satisfies the dep, then it's easier to map since we can use the fact that the installed dependency matches the *DEPEND atom to determine when the atom needs to be updated (and potentially how it needs to be updated, if subslots are involved).
(In reply to Ulrich Müller from comment #7) > (In reply to Ian Stakenvicius from comment #4) > > By definition that can't happen. The range specified in <spec> specifies > > what is moved. Everything that matches that range gets moved. Something > > cannot match that range and not be moved. > > Simple example: > - cat/foo-1 and cat/foo-2 both have SLOT="0" > - cat/bar has RDEPEND="cat/foo:0" > > Now foo-2 is updated to SLOT=2 and a "slotmove =cat/foo-2 0 2" is done. > Do you update the dependency of the installed cat/bar? For this particular case, IMO we would update the VDB of cat/bar if cat/foo-2 is installed, and not if cat/foo-2 isn't installed. The only reason to update *DEPEND of the vdb is if the change to the installed cat/foo directly affects the rdeps of cat/foo, right? If neither cat/foo-1 nor cat/foo-2 are installed, say cat/bar's dep is actually RDEPEND="|| ( cat/baz:0 cat/foo:0 )" and cat/baz:0 is installed, then i think #1 cat/foo:0 should only be updated if the "slotmove" spec encapsulates the *DEPEND atom, ie, only "slotmove cat/foo 0 2" would change it, and #2 we should clarify this type of guidance in PMS to make clear all of the do-change and do-not-change cases, or at least to provide the recommendation. Having these clear rules would help dev's do proper slotmove specifications as well imo, based on what the *DEPEND is of the rdeps.
(In reply to Ian Stakenvicius from comment #9) > #2 we should clarify this type of guidance in PMS to make clear all > of the do-change and do-not-change cases, or at least to provide the > recommendation. Having these clear rules would help dev's do proper > slotmove specifications as well imo, based on what the *DEPEND is of the > rdeps. ..actually i take that back; we need to document this in the devmanual, but PMS can remain as-is because VDB isn't specified in PMS.
(In reply to Ciaran McCreesh from comment #1) > It would be easier to deprecate updates entirely. They're painfully fragile. That might be a solution, but then people will complain about "useless rebuilds" (which we had for the ncurses mess anyway). It's the same debate we had with dynamic dependencies. They are fragile, but people liked it. But yeah, with git... such manual mass updates would be relatively easy and TESTABLE.
(In reply to Ian Stakenvicius from comment #10) > (In reply to Ian Stakenvicius from comment #9) > > #2 we should clarify this type of guidance in PMS to make clear all > > of the do-change and do-not-change cases, or at least to provide the > > recommendation. Having these clear rules would help dev's do proper > > slotmove specifications as well imo, based on what the *DEPEND is of the > > rdeps. > > ..actually i take that back; we need to document this in the devmanual, but > PMS can remain as-is because VDB isn't specified in PMS. Yes, and we got just another versioned spec slotmove: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6ffa2944518401bc01c61a5cba45fbad1ef1a851 When asked, he responded "I wasn't aware that some random bug constitutes policy." So I guess we should just make it policy.
(In reply to Julian Ospald (hasufell) from comment #12) > (In reply to Ian Stakenvicius from comment #10) > > (In reply to Ian Stakenvicius from comment #9) > > > #2 we should clarify this type of guidance in PMS to make clear all > > > of the do-change and do-not-change cases, or at least to provide the > > > recommendation. Having these clear rules would help dev's do proper > > > slotmove specifications as well imo, based on what the *DEPEND is of the > > > rdeps. > > > > ..actually i take that back; we need to document this in the devmanual, but > > PMS can remain as-is because VDB isn't specified in PMS. > > Yes, and we got just another versioned spec slotmove: > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=6ffa2944518401bc01c61a5cba45fbad1ef1a851 > > When asked, he responded "I wasn't aware that some random bug constitutes > policy." That's because it doesn't. The current situation is that versioned slotmoves are a documented feature that has been used numerous times in the past. The package in question has exactly one revdep, no subslots involved, and tested OK. > > So I guess we should just make it policy. Then send a patch to PMS team.
(In reply to Michael Palimaka (kensington) from comment #13) > (In reply to Julian Ospald (hasufell) from comment #12) > > (In reply to Ian Stakenvicius from comment #10) > > > (In reply to Ian Stakenvicius from comment #9) > > > > #2 we should clarify this type of guidance in PMS to make clear all > > > > of the do-change and do-not-change cases, or at least to provide the > > > > recommendation. Having these clear rules would help dev's do proper > > > > slotmove specifications as well imo, based on what the *DEPEND is of the > > > > rdeps. > > > > > > ..actually i take that back; we need to document this in the devmanual, but > > > PMS can remain as-is because VDB isn't specified in PMS. > > > > Yes, and we got just another versioned spec slotmove: > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > > ?id=6ffa2944518401bc01c61a5cba45fbad1ef1a851 > > > > When asked, he responded "I wasn't aware that some random bug constitutes > > policy." > > That's because it doesn't. The current situation is that versioned slotmoves > are a documented feature that has been used numerous times in the past. The > package in question has exactly one revdep, no subslots involved, and tested > OK. > I concurr on this one -- there isn't a problem doing versioned slot moves per se, there's just (right now) a problem in the portage vdb when it happens due to the rdeps not getting updated, and how that affects slot-operator-dep calculations in certain circumstances. There's no need to ban them even right now when we know portage doesn't do all necessary steps, as long as the impact is known and is contained.
(In reply to Ian Stakenvicius from comment #14) > > I concurr on this one -- there isn't a problem doing versioned slot moves > per se, there's just (right now) a problem in the portage vdb when it > happens due to the rdeps not getting updated, and how that affects > slot-operator-dep calculations in certain circumstances. There's no need to > ban them even right now when we know portage doesn't do all necessary steps, > as long as the impact is known and is contained. It's not enough to just care about portage (which I do not use). This affects the whole gentoo ecosystem. And developers saying "I tested it on portage" is not enough either, because we are supposed to code against PMS while following gentoo policies.
(In reply to Julian Ospald (hasufell) from comment #15) > (In reply to Ian Stakenvicius from comment #14) > > > > I concurr on this one -- there isn't a problem doing versioned slot moves > > per se, there's just (right now) a problem in the portage vdb when it > > happens due to the rdeps not getting updated, and how that affects > > slot-operator-dep calculations in certain circumstances. There's no need to > > ban them even right now when we know portage doesn't do all necessary steps, > > as long as the impact is known and is contained. > > It's not enough to just care about portage (which I do not use). This > affects the whole gentoo ecosystem. > > And developers saying "I tested it on portage" is not enough either, because > we are supposed to code against PMS while following gentoo policies. I agree on the points you make here. The issue that brought this up relates to how PORTAGE (not any other PM) handles (or rather doesn't handle) VDB updates on its own VDB (which is PM specific) with versioned slotmoves. Other PMs don't have the issue that prevents dev's from filing versioned slotmoves because they either (A) ignore the slotmove (or updates/ entirely), as is their choice as PMS doesn't specify how a PM should manage their VDB or even what to file in their VDB, and/or (B) likely handle them appropriately, as per PMS spec, since versioned slotmove operations has been in the spec for a very long time. (note - if other PMs are failing to handle versioned slotmove op's properly and would benefit from the abolition of slotmoves on anything other than a whole package, please report!) This is why #1 I don't see any issue with dev's continuing to use versioned slotmove operations so long as they mitigate the fact that portage is currently not handling VDB updates properly, and #2 why I don't see we should change the spec just so that portage's slotmove VDB update code doesn't have to be fixed. So in summary, IMO PMS is fine but portage (especially after EAPI5 subslot additions to VDB) needs fixing.
Closing per comment #16. This is not a PMS issue, but an issue with the VDB (of which PMS explicitly says that it is unspecified). Feel free to reassign to dev-portage and reopen.
