Bug 455904 – PMS is unclear on the meaning of subslots

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

[Description Alexis Ballier 2013-02-06 20:27:09 UTC]

From http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-660007.2 :
The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt.


IMHO it should be made more precise:
- Does this mean an ABI change? (e.g. lib major changed for .so)
- An ABI addition ?
- Something else ?
- What are the dependent pakages ? All of them ?
- What does this 'may' means ?

Let's take the dev-libs/glib example: gobject-introspection has to be rebuilt after each minor update of glib, otherwise it breaks. Should glib set SLOT=2/$PV ? SLOT=2/2 ?

In the former case, gobject-introspection breakages can be easily caught and rebuilt automatically. But then, if another package := depends on glib for the ABI part (so that subslot can be a substitute to preserve-libs) then this will trigger a useless rebuild. In the latter case, there will be no useless rebuild but gobject-introspection will not be rebuilt either after minor bumps.

Other example: icu 0.50.1.1 sets SLOT=0/${PV}, libpng 1.5.14 sets SLOT="0/15", which appear to mean 'ABI', so can be used as a substitute to preserve-libs.

subslots are nice but misusage of them around the tree can cause severe nuisance (webkit-gtk started to use subslots...), so IMHO it's quite important to make it clear what are the valid usecases and what are not.

At the very least, PMS should mention to check with the relevant package maintainer the meaning of its package subslot so that one can avoid useless rebuilds.

[Comment 1 Ciaran McCreesh 2013-02-06 20:36:43 UTC]

PMS specifies invariants. It's up to you how you make use of those invariants. The specification of subslots has *nothing* to do with ABIs, whatever an ABI is. You can use subslots for dealing with ABIs if you like, but PMS doesn't care. The valid use cases are precisely those where the mechanism specified for subslots is what you want.

If you want more guidance on how to use subslots in practice, that's a devmanual thing.

[Comment 2 Alexis Ballier 2013-02-06 21:01:05 UTC]

(In reply to comment #1)
> PMS specifies invariants. It's up to you how you make use of those
> invariants. The specification of subslots has *nothing* to do with ABIs,
> whatever an ABI is. You can use subslots for dealing with ABIs if you like,
> but PMS doesn't care.

Agreed, but the wording is vague so it should be made clear it is done on purpose.

> The valid use cases are precisely those where the
> mechanism specified for subslots is what you want.

What's wrong with adding such a comment after the sentence I quoted ?
Otherwise you could also simply remove that sentence, it's not an invariant either, only a temptative vague and confusing interpretation of subslots, and could also go to devmanual being much more precise.

[Comment 3 Ulrich Müller 2013-08-09 11:27:49 UTC]

(In reply to Alexis Ballier from comment #2)
> What's wrong with adding such a comment after the sentence I quoted ?

Can you provide a patch please, so that we have a concrete wording for discussion?

[Comment 4 Alexis Ballier 2013-08-09 12:28:27 UTC]

(manual patch)
- The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt.
+ An upgrade to a new version of a package with a different sub-slot requires the package manager to rebuild dependent packages.


(maybe change the upgrade wording too since its the case for downgrades also...)

It's an invariant; usage can go to devmanual.

[Comment 5 Ciaran McCreesh 2013-08-09 12:33:41 UTC]

But that's wrong: the package mangler may take other actions instead of rebuilding dependent packages, such as uninstalling them or installing a different version.

[Comment 6 Alexis Ballier 2013-08-09 12:40:52 UTC]

(In reply to Ciaran McCreesh from comment #5)
> But that's wrong: the package mangler may take other actions instead of
> rebuilding dependent packages, such as uninstalling them or installing a
> different version.

not more than the current wording then...

+ Installing a package in the same SLOT but with a different sub-slot breaks the dependent packages.

[Comment 7 Arne Babenhauserheide 2016-04-17 09:29:39 UTC]

(In reply to Alexis Ballier from comment #6)
> (In reply to Ciaran McCreesh from comment #5)
> > But that's wrong: the package mangler may take other actions instead of
> > rebuilding dependent packages, such as uninstalling them or installing a
> > different version.
> 
> not more than the current wording then...
> 
> + Installing a package in the same SLOT but with a different sub-slot breaks
> the dependent packages.

Maybe with a "might":

+ Installing a package in the same SLOT but with a different sub-slot might break
dependent packages.

(I’m stumbling over subslot dependencies right now, with conflicts I cannot resolve easily, which is what got me here)

[Comment 8 Larry the Git Cow 2023-12-10 22:01:51 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/portage.git/commit/?id=ee127db438307c133fcf650c148ed594ceb68591

commit ee127db438307c133fcf650c148ed594ceb68591
Author:     Sam James <[e-mail]>
AuthorDate: 2023-09-04 17:40:06 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2023-12-10 22:01:48 +0000

    dep: add comment to _eval_deps wrt binding slot deps in any-of || ( ... )
    
    Bug: https://bugs.gentoo.org/455904
    Bug: https://bugs.gentoo.org/489458
    Bug: https://bugs.gentoo.org/586238
    Signed-off-by: Sam James <[e-mail]>

 lib/portage/dep/_slot_operator.py | 1 +
 1 file changed, 1 insertion(+)