Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 493742 - sys-apps/portage: please make repoman complain about dependencies without slots in EAPI=5+
Summary: sys-apps/portage: please make repoman complain about dependencies without slo...
Status: RESOLVED WONTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Repoman (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 497920 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-12-09 11:16 UTC by Michał Górny
Modified: 2022-07-12 03:30 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2013-12-09 11:16:55 UTC
A few points:

1. if package is not slotted yet, it may become slotted in the future and this will cause a lot of pain, so you should go for :<current-slot> anyway,

2. if package is slotted and you need to bind to the slot, you need to use :=,

3. if package is slotted and you accept switching slots at runtime, you need to use :* [1].


This makes the non-slotted dep basically mean 'I have no idea' which is bad for QA and causes inconsistent behavior. Since starting with EAPI 5, we have all the operators we need, we should explicitly encourage developers to use them.


[1]:http://article.gmane.org/gmane.linux.gentoo.devel/89135
Comment 1 Sebastian Luther (few) 2014-01-01 19:04:04 UTC
(In reply to Michał Górny from comment #0)

> 1. if package is not slotted yet, it may become slotted in the future and
> this will cause a lot of pain, so you should go for :<current-slot> anyway,

You could cause a lot of pain this way too. If you want to slot-move away from <current-slot> you'll need to touch each and every reverse dependency.

It's also different from 2. and 3. in that in the latter cases you don't require any hardcoding of slots.

If another slot is ever introduced you'll have to switch all reverse dependencies to :* or := anyway, which means that a dependency without a slot operator always refers to <current-slot>, because the absence of a slot operator implies, that there's only one slot.

> 2. if package is slotted and you need to bind to the slot, you need to use
> :=,
> 
> 3. if package is slotted and you accept switching slots at runtime, you need
> to use :* [1].
> 

Makes sense.
Comment 2 Sebastian Luther (few) 2014-01-12 18:36:16 UTC
*** Bug 497920 has been marked as a duplicate of this bug. ***
Comment 3 Sebastian Luther (few) 2014-01-12 18:39:41 UTC
I send a patch implementing 1 and 2 to the ml:
http://article.gmane.org/gmane.linux.gentoo.portage.devel/3829
Comment 4 Sebastian Luther (few) 2014-01-12 18:45:54 UTC
(In reply to Sebastian Luther (few) from comment #3)
> I send a patch implementing 1 and 2 to the ml:
> http://article.gmane.org/gmane.linux.gentoo.portage.devel/3829

It's 2 and 3 actually.
Comment 5 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-03-10 11:02:48 UTC
(In reply to Sebastian Luther (few) from comment #1)
> (In reply to Michał Górny from comment #0)
> 
> > 1. if package is not slotted yet, it may become slotted in the future and
> > this will cause a lot of pain, so you should go for :<current-slot> anyway,
> 
> You could cause a lot of pain this way too. If you want to slot-move away
> from <current-slot> you'll need to touch each and every reverse dependency.

:* causes more pain as it keeps us from slotting things in the first place; see for example, the libsdl2 case (bug #493652). Touching each and every reverse dependency will become easier when the git migration is done.

> It's also different from 2. and 3. in that in the latter cases you don't
> require any hardcoding of slots.

This is a comparison, but not an argument; can you demonstrate why not hardcoding is a better idea than hardcoding? 

> If another slot is ever introduced you'll have to switch all reverse
> dependencies to :* or := anyway,

That is a guess; it is more likely that if you set it :0, it'll stay :0. That's given that when people slot something, they often leave the old versions in :0; this maintainer behavior also creates a natural migration period by itself.

As a side note; imo, slotmoves should be an exception, not a rule.

> which means that a dependency without a
> slot operator always refers to <current-slot>, because the absence of a slot
> operator implies, that there's only one slot.

It actually refers to <highest-slot>; which is <current-slot> right now, but that can change in the future. AutoRepoMan reports this to us in hours instead of having to wait one or more days to hear this in the news (bug, forum, ...).

> > 2. if package is slotted and you need to bind to the slot, you need to use
> > :=,
> > 
> > 3. if package is slotted and you accept switching slots at runtime, you need
> > to use :* [1].
> > 
> 
> Makes sense.

+1
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2014-03-10 14:04:44 UTC
TomWJI seems to think this bug is an excuse for guessing packages like virtual/pkgconfig, dev-util/intltool, etc. will always be in SLOT="0" and that SLOT="0" will have the files most packages require.
That's most likely not how it will go.

For eg.

dev-python/eyeD3 new version went to SLOT="0.7" when old version was in SLOT="0", so if all the packages using dev-python/eyeD3 would have been setting :0, that would have been broken and they would have pulled in the older SLOT without the eyeD3 executable.

So if package only has one SLOT, repoman should be quiet about it, otherwise you causing more work to maintainers since before slotmoving, or adding new version to new SLOT, he'd have to go through entire gentoo-x86 and fix the guessed SLOTs
Comment 7 Sebastian Luther (few) 2014-03-10 19:04:04 UTC
(In reply to Tom Wijsman (TomWij) from comment #5)
> 
> > It's also different from 2. and 3. in that in the latter cases you don't
> > require any hardcoding of slots.
> 
> This is a comparison, but not an argument; can you demonstrate why not
> hardcoding is a better idea than hardcoding? 

The comparison shows that the three cases aren't handled in a consistent way. Some hard code, some not. Being consistent is better, imo.

> 
> > If another slot is ever introduced you'll have to switch all reverse
> > dependencies to :* or := anyway,
> 
> That is a guess; it is more likely that if you set it :0, it'll stay :0.
> That's given that when people slot something, they often leave the old
> versions in :0; this maintainer behavior also creates a natural migration
> period by itself.
> 
You're replacing one guess with another one. My approach means consistency between between all three cases, less work for maintainers, less noise in *DEPEND.

> > which means that a dependency without a
> > slot operator always refers to <current-slot>, because the absence of a slot
> > operator implies, that there's only one slot.
> 
> It actually refers to <highest-slot>; which is <current-slot> right now, but
> that can change in the future. 

The implication of what I said is, that if you add a second slot to your package your're responsible to add slot operators to your reverse dependencies (or at least start some process to get them added). Only then adding hard coded slots is no longer guessing.
Comment 8 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-03-10 22:27:03 UTC
Agreed with comment #6 up to a certain extent (limited to mentioned pkgs).

(In reply to Sebastian Luther (few) from comment #7)
> (In reply to Tom Wijsman (TomWij) from comment #5)
> > 
> > > It's also different from 2. and 3. in that in the latter cases you don't
> > > require any hardcoding of slots.
> > 
> > This is a comparison, but not an argument; can you demonstrate why not
> > hardcoding is a better idea than hardcoding? 
> 
> The comparison shows that the three cases aren't handled in a consistent
> way. Some hard code, some not. Being consistent is better, imo.

Can this consistency be demonstrated as a better idea?

Otherwise we can make everything hardcoded; or take a look at how hardcoded is perceived as bad practice in software developers by others and avoid hardcoding anything at all, it really depends on the context if it is a better idea.

> > > If another slot is ever introduced you'll have to switch all reverse
> > > dependencies to :* or := anyway,
> > 
> > That is a guess; it is more likely that if you set it :0, it'll stay :0.
> > That's given that when people slot something, they often leave the old
> > versions in :0; this maintainer behavior also creates a natural migration
> > period by itself.
> > 
> You're replacing one guess with another one. My approach means consistency
> between between all three cases, less work for maintainers, less noise in
> *DEPEND.

It's more a perception than a guess; as from what I can see in the Portage tree, I see this happen in general. This is also deducible from that if they rely on people depending on the newer version, SLOT 0 loses the need to be present; it'll break the dependency contract in one way or another that way.

As maintainer, I'm willing to put in the work and noise for better maintenance; however, granted, the idea with repoman should be that everyone would want this _or_ it is deemed to be as good QA _or_ it has been decided per consensus. Given that we have neither of those; it becomes questionable to add this, I think that it should be brought up for more discussion and/or meeting votes.

> > > which means that a dependency without a
> > > slot operator always refers to <current-slot>, because the absence of a slot
> > > operator implies, that there's only one slot.
> > 
> > It actually refers to <highest-slot>; which is <current-slot> right now, but
> > that can change in the future. 
> 
> The implication of what I said is, that if you add a second slot to your
> package your're responsible to add slot operators to your reverse
> dependencies (or at least start some process to get them added). Only then
> adding hard coded slots is no longer guessing.

Agreed wrt that implication. Whether something is guessing depends on what is perceived as the default contract that is bound with a slot dependency; there are different viewpoints on this from within Gentoo, some perceive this as a defined interface whereas others use a different approach and see it as possible to change the defined interface. Alongside this comes the way with how such change is being addressed; if done appropriately, I think both cases are appropriate here. Much of discussion is about the safe guarding of what happens when it's not appropriately done; said otherwise, defensive programming.
Comment 9 Pacho Ramos gentoo-dev 2015-09-18 15:16:48 UTC
This check is now a bit more interesting because, if finally "dynamic-deps" in portage are disabled a really common problem is:
- Tons of package RDEPEND on A
- Long time after that, A starts to have a new SLOT
- As most reverse deps need to be ported, we need to fix it retroactively.

Currently, we can see how most of us try to "run" to fix the dependencies to set the proper slot but this relies on dynamic-deps, if they are disabled, we will need to make revbumps for all of them and people will need to rebuild them. This can be a bit tedious... I can think on recent examples like gstreamer, gtk+, glib... 

On the other hand, if we start always setting the available slots that we know to work, we can avoid this issue

Thanks
Comment 10 Pacho Ramos gentoo-dev 2015-09-18 15:18:33 UTC
(In reply to Pacho Ramos from comment #9)
This can be a bit tedious... I can think on recent examples
> like gstreamer, gtk+, glib... 
> 

by "tedious" I mean that people will need to rebuild ALL reverse deps of important libs like glib, gtk... and they can be really a lot
Comment 11 Zac Medico gentoo-dev 2015-09-18 21:32:25 UTC
This is has been fixed since 2.2.16:

https://gitweb.gentoo.org/proj/portage.git/commit/?id=d87ed03875c709b451a9e512d74f9b3d9c689271
Comment 12 Pacho Ramos gentoo-dev 2015-09-19 09:04:15 UTC
Umm, it's strange then, because even with latest repoman I get no warning if package has only one slot, and, then, the problem of needing to add SLOTs later if the package is slotted in the future is still there :/
Comment 13 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2015-09-19 09:31:08 UTC
Well, I implemented what people were able to accept. We can keep the bug open for the original proposal but I doubt Gentoo developers are going to accept it.
Comment 14 Zac Medico gentoo-dev 2015-09-19 18:10:17 UTC
(In reply to Pacho Ramos from comment #12)
> Umm, it's strange then, because even with latest repoman I get no warning if
> package has only one slot, and, then, the problem of needing to add SLOTs
> later if the package is slotted in the future is still there :/

There are two distinctly different possibilities:

a) A specific slot needs to be hardcoded
b) A :* slot operator is appropriate

How are we supposed to predict which of the above two cases we will encounter for any given dependency?
Comment 15 Zac Medico gentoo-dev 2015-09-19 18:21:41 UTC
(In reply to Zac Medico from comment #14)
> How are we supposed to predict which of the above two cases we will
> encounter for any given dependency?

If we can come up with some heuristics for this, then we'll be in a position to make predictions.
Comment 16 Pacho Ramos gentoo-dev 2015-09-20 08:26:19 UTC
You cannot assume that any slot in the future will work with your package, then, by default, we should stick with the existing one, the one that we can really test and, if in the future a new slot appears AND we check that it also works, we can use :*
Comment 17 Zac Medico gentoo-dev 2015-09-20 16:59:28 UTC
(In reply to Pacho Ramos from comment #16)
> You cannot assume that any slot in the future will work with your package,
> then, by default, we should stick with the existing one, the one that we can
> really test and, if in the future a new slot appears AND we check that it
> also works, we can use :*

Using that logic, the :* operator should be banned, since "You cannot assume that any slot in the future will work with your package."
Comment 18 Zac Medico gentoo-dev 2015-09-20 17:02:45 UTC
In order to minimize changes to dependencies of existing ebuilds, isn't it safer to use :* and only hardcode a specific slot when it's found to be necessary?
Comment 19 Zac Medico gentoo-dev 2015-09-20 17:28:53 UTC
(In reply to Zac Medico from comment #18)
> In order to minimize changes to dependencies of existing ebuilds, isn't it
> safer to use :* and only hardcode a specific slot when it's found to be
> necessary?

We should do a statistical analysis of known dependency relationships, to see whether the :* or the hardcoded slot is more probable.
Comment 20 Pacho Ramos gentoo-dev 2015-09-20 17:34:55 UTC
Personally I wouldn't let something like :* to exist and would prefer to set something like ranges of SLOTs that are known to work. I think that most of the times we need to SLOT a library is when they break compatibility with older versions and, then, most reverse deps will need to be ported (and, then, won't work as-is like it's done currently with the latest slot and neither will work as-is with any slot that could appear in the tree).

(In reply to Zac Medico from comment #18)
> In order to minimize changes to dependencies of existing ebuilds, isn't it
> safer to use :* and only hardcode a specific slot when it's found to be
> necessary?

I think that we can simply try to look to the recent history to see that it's much more common to need to retroactively fix dependencies to specify the slot that reverse dep need, I haven't seen so many cases of reverse deps being ok with :* (well, in the area I mostly take care, most gnome team maintained libs, like glib, gtk+... I have even needed to still fix wrongly deps of packages that were using gtk2 but wrongly pulling gtk3 because no slot was specified, I remember the same cases long time ago with glib-1 and glib-2... also with gstreamer... you can even check the git logs from the past week to see that dotnet maintainers needed to fix retroactively the reverse deps of dbus-sharp consumers because, as usual, reverse deps are not magically supporting all slots without patching/updating them)
Comment 21 Pacho Ramos gentoo-dev 2015-09-20 17:37:38 UTC
And many more cases (well, you can simply grep in the old ChangeLogs for something like "SLOT" and you will see how often is we needing to fix dependencies to specify the right slot when, for example, webkit-gtk, jpeg, libpng slots are bumped)
Comment 22 Zac Medico gentoo-dev 2015-09-20 17:39:43 UTC
Why don't we make it an warning (to become an error in the future) if they don't use :* or hardcode a specific slot with EAPI 5 or later? That way, the ebuild maintainers are forced to choose one way or the other.
Comment 23 Pacho Ramos gentoo-dev 2015-09-20 17:51:37 UTC
I don't have a strong opinion on making it an error or just a warning now with current EAPI. Maybe the best option would be to make it a warning now and maybe force it in the next EAPI (for example, there are still eapi0 ebuilds that won't be able to set proper slots and will still rely on using forms like =${CATEGORY}/${P}-X*

The only thing that I pretend is to try to progressively stop doing this kind of error that, until now, forced us to need to fix reverse dependencies retroactively and that now, in addition, will also require to revbump all reverse deps and, instead, try to set the "safest" and known to work dependencies at the start... letting us to not need to fix them after that or, even, if a package is found to work with newer slot too, fix the dep on a new version even delaying it a bit to, for example, take advantage of a future version going to be stabilized for other reasons. We would be able to delay the change from :0 to :* because the package would still work in the tree as it already has the correct dependendencies pulling a SLOT that works. 

On the other hand, with current situation, we aren't be able to do postpone the need of setting the concrete SLOT because (and forcing the rebuild) because, otherwise, people will start to get the bug as soon as they install the newer (and incompatible) slot
Comment 24 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-12 03:18:13 UTC
repoman support has been removed per bug 835013.

Please file a new bug (or, I suppose, reopen this one) if you feel this check is still applicable to pkgcheck and doesn't already exist.
Comment 25 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-07-12 03:30:43 UTC
pkgcheck has MissingSlotDep.