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.
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.
(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.
(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?
(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.
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.
(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.
(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)
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 <sam@gentoo.org> AuthorDate: 2023-09-04 17:40:06 +0000 Commit: Sam James <sam@gentoo.org> 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 <sam@gentoo.org> lib/portage/dep/_slot_operator.py | 1 + 1 file changed, 1 insertion(+)
