Bug 546826 – Redundancy between 2-style and 4-style usedeps

• Product: Gentoo Linux
• Status: RESOLVED WONTFIX

[Description Alexis Ballier 2015-04-16 17:53:57 UTC]

Currently, we have 3 types of usedeps:

a) cat/pkg[opt]
b) cat/pkg[opt(-)]
c) cat/pkg[opt(+)]


All three are equivalent if cat/pkg exposes the opt useflag.
They differ only when it doesn't and mean:
a) is an error
b) considers it disabled
c) considers it enabled

I don't see the point of keeping a) around, except for leaving room for developers to trigger unspecified/invalid behavior.


In a future eapi we could either:

1. kill b), make a) mean cat/pkg[opt(-)]
2. kill a)

[Comment 1 Ulrich Müller 2015-04-16 19:00:40 UTC]

The problem is that one cannot know in advance if [opt(-)] or [opt(+)] will be right. If a package always had the opt flag, and it is removed at some point, then it could mean either that the "opt" feature is removed, or that it is enabled unconditionally.

[Comment 2 Alexis Ballier 2015-04-17 09:13:50 UTC]

(In reply to Ulrich Müller from comment #1)

Well, yes, but this is irrelevant to the above: if opt is removed, cat/pkg[opt] is an error according to pms. option 2. sums up to asking developers to chose explicitly.


Another option, which is what portage seems to do, is to consider 2-style usedeps when cat/pkg doesn't expose the useflag to never be satisified, as:
- cat/pkg[foo] <=> cat/pkg[foo(-)]
- cat/pkg[-foo] <=> cat/pkg[-foo(+)]

[Comment 3 Zac Medico 2015-04-17 19:41:39 UTC]

(In reply to Alexis Ballier from comment #2)
> (In reply to Ulrich Müller from comment #1)
> 
> Well, yes, but this is irrelevant to the above: if opt is removed,
> cat/pkg[opt] is an error according to pms. option 2. sums up to asking
> developers to chose explicitly.

They'll have to forsee the future in order to do that, which obviously is not possible (unless they have a crystal ball or something).

[Comment 4 Ulrich Müller 2015-04-18 06:03:55 UTC]

The spec says (https://projects.gentoo.org/pms/5/pms.html#x1-870008.2.6.4):
"Unless a 4-style default is specified, it is an error for a use dependency to be applied to an ebuild which does not have the flag in question in IUSE_REFERENCEABLE."

A dependency can either be satisfied or not. For example, if the package atom specified is not in the tree (which can be valid usage for || ( ) dependencies or for blockers) then simply does not match, but it is not an error.

Therefore it seems unsystematic to say "it is an error" for the specific case that the target of a use dependency doesn't have the flag. Also, how is the package manager supposed to handle that error? Treat the ebuild specifying the dependency as masked ("by corruption")?

Maybe we should change/clarify the wording. It should say that such a use dependency is not satisfied, i.e. in the following sense:

(In reply to Alexis Ballier from comment #2)
> Another option, which is what portage seems to do, is to consider 2-style
> usedeps when cat/pkg doesn't expose the useflag to never be satisified, as:
> - cat/pkg[foo] <=> cat/pkg[foo(-)]
> - cat/pkg[-foo] <=> cat/pkg[-foo(+)]

"Unless a 4-style default is specified, a use dependency does not match if applied to an ebuild which does not have the flag in question in IUSE_REFERENCEABLE."

[Comment 5 Alexis Ballier 2015-04-18 10:32:30 UTC]

(In reply to Ulrich Müller from comment #4)
> The spec says (https://projects.gentoo.org/pms/5/pms.html#x1-870008.2.6.4):
> "Unless a 4-style default is specified, it is an error for a use dependency
> to be applied to an ebuild which does not have the flag in question in
> IUSE_REFERENCEABLE."
> 
> A dependency can either be satisfied or not. For example, if the package
> atom specified is not in the tree (which can be valid usage for || ( )
> dependencies or for blockers) then simply does not match, but it is not an
> error.

yes, indeed

> Therefore it seems unsystematic to say "it is an error" for the specific
> case that the target of a use dependency doesn't have the flag. Also, how is
> the package manager supposed to handle that error? Treat the ebuild
> specifying the dependency as masked ("by corruption")?

This is one way, a repoman error could be a good not so harsh solution too.

> Maybe we should change/clarify the wording. It should say that such a use
> dependency is not satisfied, i.e. in the following sense:
> 
> (In reply to Alexis Ballier from comment #2)
> > Another option, which is what portage seems to do, is to consider 2-style
> > usedeps when cat/pkg doesn't expose the useflag to never be satisified, as:
> > - cat/pkg[foo] <=> cat/pkg[foo(-)]
> > - cat/pkg[-foo] <=> cat/pkg[-foo(+)]
> 
> "Unless a 4-style default is specified, a use dependency does not match if
> applied to an ebuild which does not have the flag in question in
> IUSE_REFERENCEABLE."

+1

after all, this is the one that makes most sense to me now.

[Comment 6 Ciaran McCreesh 2015-04-18 16:46:33 UTC]

The point of this is to catch developer mistakes. Without it there's no way of knowing whether a developer has checked the behaviour, or just forgotten to do something about it.

[Comment 7 Ulrich Müller 2019-11-25 08:32:23 UTC]

Closing per comment #6.