Well, subslots were added a long time after slotmoves were defined, and it seems that the people pushing for them didn't document how slotmoves are supposed to apply to them. I'm going to try to do some research on this and put the results down here. The main problems I see are: 1. SLOT="1" slotmove ... 1 2 The package has implicit slot/subslot 1/1. What is the subslot after move? Is it 2/2 or 2/1? 2. SLOT="1/10" slotmove ... 1 2 Is the package going to be moved at all? What is the subslot after move? Is it 2/10 or is it implicitly reset to 2/2? 3. SLOT="0/10" slotmove ... 0/10 0/11 Is this legal (given EAPI=5 in profiles)?
So, FWICS in Portage source code, its behavior is quite curious: if "/" not in newslot and \ mycpv.sub_slot and \ mycpv.sub_slot not in (mycpv.slot, newslot): newslot = "%s/%s" % (newslot, mycpv.sub_slot) (changed the indent for readability) So, basically it preserves the original subslot unless it was equal to the original slot or target slot (in which case, isn't it equivalent to replacing it?). So, in case of Portage: 1. 2/2 2. 2/10 3. valid
pkgcore seems to have some slotmove collecting code followed by a no-op. Paludis seems to support plain slots only, and simply overwrites the SLOT in vdb with the new one (so 2/2 for both).
Also: slotmove app-misc/foo:1 1 2 Is this legal? PMS says that the first parameter is a package dependency specification which in EAPI 1 and later can contain a slot dependency.
(In reply to Ulrich Müller from comment #3) > Also: > > slotmove app-misc/foo:1 1 2 > > Is this legal? PMS says that the first parameter is a package dependency > specification which in EAPI 1 and later can contain a slot dependency. That depends if the pkgmove gets rewritten as a part of the pkgmove ;-). Also: slotmove app-misc/foo:3 1 2 So: Portage replaces the slot from the atom with the one from origslot. So both forms would move foo:1 -> :2. pkgcore explicitly rejects atoms with slot part. Paludis just stacks filters, so I suppose the first one may work (not sure if it doesn't require EAPI 0 for atoms though), and the second one will match no packages.
I seem to recall that when we wrote that, profiles were locked to EAPI 0, and I had a general moan about not moving them off EAPI 0 until we'd figured out what happened with fancy dependencies in all these different files...
So, the first question is what we want the spec to be in EAPI 7? Quoting the current wording for reference: move <qpn1> <qpn2> slotmove <spec> <slot1> <slot2> [...] 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. - Should we forbid slot dependencies in <spec>? They seem to be redundant with <slot1>. OTOH, I don't see any harm in allowing them (and nobody will use them anyway). - For <slot1>, the usual rules for matching a slot dependency should apply: https://projects.gentoo.org/pms/6/pms.html#x1-880008.2.6.3 - For <slot2>, I suggest that the resulting slot of the package should be equal to the one that would result for a new ebuild with SLOT=<slot2>. The second question is what we do for existing EAPIs. Can we do any better than saying that behaviour for subslots is undefined?
Well, I think the only really reasonable way to deal with subslots is to provide a separate move for every subslot, i.e.: slotmove dev-foo/bar 1/1 2/1 slotmove dev-foo/bar 1/2 2/2 and so on. But then, people will also probably want a generic fallback in case of different subslot...
(In reply to Michał Górny from comment #7) > Well, I think the only really reasonable way to deal with subslots is to > provide a separate move for every subslot, i.e.: > > slotmove dev-foo/bar 1/1 2/1 > slotmove dev-foo/bar 1/2 2/2 > > and so on. Yes, I'd also say that things should be explicit there. I wouldn't want to complicate it further by keeping any previous subslot (while the slot itself changes). > But then, people will also probably want a generic fallback in case of > different subslot... I hope we can assume that the number of ebuilds in one slot of one package is small enough that we don't have to worry about that.
