Bug 630806 – PMS: relation between slotmoves and subslots is not properly documented

• Product: Gentoo Hosted Projects
• Status: CONFIRMED ---

[Description Michał Górny 2017-09-12 14:23:34 UTC]

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)?

[Comment 1 Michał Górny 2017-09-12 14:27:55 UTC]

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

[Comment 2 Michał Górny 2017-09-12 14:31:42 UTC]

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).

[Comment 3 Ulrich Müller 2017-09-12 14:34:04 UTC]

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.

[Comment 4 Michał Górny 2017-09-12 17:15:26 UTC]

(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.

[Comment 5 Ciaran McCreesh 2017-09-12 17:24:27 UTC]

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...

[Comment 6 Ulrich Müller 2017-09-13 13:47:55 UTC]

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?

[Comment 7 Michał Górny 2017-09-13 14:48:20 UTC]

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...

[Comment 8 Ulrich Müller 2017-09-13 15:19:22 UTC]

(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.