Mailing List Archive: [RFC] USE flags requirements (EAPI-4 ?)

[RFC] USE flags requirements (EAPI-4 ?)

Aug 30, 2009, 10:06 AM

Post #1 of 11 (614 views)

Hi,

While writing and using some ebuilds, I had to deal with (pseudo) USE
flags requirements. For example, if you install mplayer with
USE="encode" the result will depend on other USE flags: if you have
USE="encode mp3", it will install lame for example. I know a few ebuilds
behave like that in the tree. We can also see some ebuilds that will
force an option if you set another one: if you set USE="-foo +bar" and
bar needs foo, it will silently set --enable-foo. Finally, they are some
ebuilds like >=ekiga-3 that will just fail if you have two USE flags
"conflicting": kontact needs kde so USE="kde -kontact" and USE="kde
kontact" are okay but USE="-kde kontact" will fail.

In my opinion, we can't keep auto-enabling some options because the user
has enabled another option without telling him and without telling the
package manager. For example, I'm a lambda user, I've set USE=kontact
but I don't know it's related to KDE, I don't have a KDE desktop and I
don't want one. With the regular behavior in the tree, kde will be
enabled silently and the user will don't have a clue about it like the
package manager. This last one is even worst because if we imagine a
library ebuild with this behavior used by other ebuilds in the tree,
EAPI-2 use dependencies will break. (foo ebuild depends on ekiga[kde],
user will have to rebuild ekiga if it has been built with USE="-kde
kontact" even if ekiga has been built with kde support or foo ebuild
depends on mplayer[mp3] should be mplayer[encode,mp3].

However, dying is probably not the best solution too.
So I think we should add a new feature in PMS already used in Exherbo
EAPI, USE flags requirements [1]. That means an ebuild should be able to
say a USE flag is available only if some other ones are in a specific state.
Let's take the mplayer example, if we have a line like this:
USE_REQUIREMENTS="encode? ( mp2 mp3 faac x264 xvid )", PM should be able
to show the user USE="mp3" will be ignored because he didn't set
USE="encode" and the PM will disable this USE flag by himself.
The same way, for ekiga:
USE_REQUIREMENTS="kde? ( kontact )", PM should be able to show the user
if he set USE="kontact", kde USE flag is enabled and the PM will enable
this USE flag by himself.

I think this new feature should help everyones life. We can also imagine
great features like a minimal USE-flag that will be something like:
USE_REQUIREMENTS="minimal? ( foo bar )" to set a list of USE flags to
disable if minimal USE flag is enabled. Combined to EAPI-1 auto-enabled
USE flags, it could help disabling all auto-enabled USE flags for some
uses... That's just an idea.

I'm not writing a GLEP draft so don't try to found an issue in the
syntax used, it's only to know if this kind of feature will be
appreciated by other users/devs than me and if it could be added to
EAPI-4 and worth to work on it.
I can write the GLEP and implement the feature in portage.

[1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions

Thanks,
Mounir

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

tanderson at gentoo

Aug 30, 2009, 12:17 PM

Post #2 of 11 (586 views)

Permalink

On Sun, Aug 30, 2009 at 07:06:02PM +0200, Mounir Lamouri wrote:
> Hi,
<snip>
> However, dying is probably not the best solution too.
> So I think we should add a new feature in PMS already used in Exherbo
> EAPI, USE flags requirements [1]. That means an ebuild should be able to
> say a USE flag is available only if some other ones are in a specific state.
> Let's take the mplayer example, if we have a line like this:
> USE_REQUIREMENTS="encode? ( mp2 mp3 faac x264 xvid )", PM should be able
> to show the user USE="mp3" will be ignored because he didn't set
> USE="encode" and the PM will disable this USE flag by himself.
> The same way, for ekiga:
> USE_REQUIREMENTS="kde? ( kontact )", PM should be able to show the user
> if he set USE="kontact", kde USE flag is enabled and the PM will enable
> this USE flag by himself.

I'm not sure acting as if the user didn't enable the USE flag is the best
option. If I manually enable the bar USE-flag I might not expect there to be an
issue and not notice that it has been silently ignored. In general I think we
should take the approach that if we can't give a user what he/she asked for we
should error out and tell him/her that there was a problem and that
such-and-such needs to be changed.

> I'm not writing a GLEP draft so don't try to found an issue in the
> syntax used, it's only to know if this kind of feature will be
> appreciated by other users/devs than me and if it could be added to
> EAPI-4 and worth to work on it.
> I can write the GLEP and implement the feature in portage.

I very much would like this feature. I've been using it in Exherbo and it's
quite useful so far. Only thing is that it'll be possible to do this sort of
thing(only you'll have to || die) with EAPI-3 as a 'if use foo; then use bar
|| die "foo needs bar"'. The question is whether it is worth it to have this
special construct for USE-flag combinations(there're far more possibilities than
the one I gave), and I'd say it is worth it.
>
> [1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions
>
> Thanks,
> Mounir
>

Regards,
Thomas
--
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

nirbheek at gentoo

Aug 30, 2009, 12:24 PM

Post #3 of 11 (593 views)

Permalink

On Sun, Aug 30, 2009 at 10:36 PM, Mounir Lamouri<volkmar@gentoo.org> wrote:
> I think this new feature should help everyones life. We can also imagine
> great features like a minimal USE-flag that will be something like:
> USE_REQUIREMENTS="minimal? ( foo bar )" to set a list of USE flags to
> disable if minimal USE flag is enabled. Combined to EAPI-1 auto-enabled
> USE flags, it could help disabling all auto-enabled USE flags for some
> uses... That's just an idea.
>

There's also bug 251179[1], which is ugly at first glance, but shows
that we don't really need an extra variable to control dependencies
between USE-flags (it *is* after all a dependency).

So, we can either use

use1? ( =${CATEGORY}/${PVR}[use2,use3,use4] )

which will probably require less changes to portage's resolver; or
something else like

use1? ( use2 use3 use4 )

The latter is unambiguous because it's not a package atom (no / ).
Either of these will work great when portage gets automatic
USE-dependency enabling.

1. http://bugs.gentoo.org/show_bug.cgi?id=251179
--
~Nirbheek Chauhan

GNOME+Mozilla Team, Gentoo

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

ciaran.mccreesh at googlemail

Aug 30, 2009, 1:50 PM

Post #4 of 11 (593 views)

Permalink

On Sun, 30 Aug 2009 19:06:02 +0200
Mounir Lamouri <volkmar@gentoo.org> wrote:
> So I think we should add a new feature in PMS already used in Exherbo
> EAPI, USE flags requirements [1]. That means an ebuild should be able
> to say a USE flag is available only if some other ones are in a
> specific state. Let's take the mplayer example, if we have a line
> like this: USE_REQUIREMENTS="encode? ( mp2 mp3 faac x264 xvid )", PM
> should be able to show the user USE="mp3" will be ignored because he
> didn't set USE="encode" and the PM will disable this USE flag by
> himself. The same way, for ekiga:
> USE_REQUIREMENTS="kde? ( kontact )", PM should be able to show the
> user if he set USE="kontact", kde USE flag is enabled and the PM will
> enable this USE flag by himself.

Is the less expressive solution you're describing still useful enough
to make it worthwhile? When we were doing this for Exherbo, we
identified five types of inter-use-flag dependency:

* if a then b
* if a then not b
* at least one of a b c, possibly only if d
* exactly one of a b c, possibly only if d
* at most one of a b c, possibly only if d

Does Gentoo make use of all of these, and are there any cases that the
above doesn't cover? How would you express each of the above using
USE_REQUIREMENTS?

From a package manager perspective, it's much easier to give good
advice to the user if we're told by the ebuild exactly what's going on.

--
Ciaran McCreesh

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

hkBst at gentoo

Aug 31, 2009, 3:52 AM

Post #5 of 11 (591 views)

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ciaran McCreesh wrote:
> On Sun, 30 Aug 2009 19:06:02 +0200
> Mounir Lamouri <volkmar@gentoo.org> wrote:
>> So I think we should add a new feature in PMS already used in Exherbo
>> EAPI, USE flags requirements [1]. That means an ebuild should be able
>> to say a USE flag is available only if some other ones are in a
>> specific state. Let's take the mplayer example, if we have a line
>> like this: USE_REQUIREMENTS="encode? ( mp2 mp3 faac x264 xvid )", PM
>> should be able to show the user USE="mp3" will be ignored because he
>> didn't set USE="encode" and the PM will disable this USE flag by
>> himself. The same way, for ekiga:
>> USE_REQUIREMENTS="kde? ( kontact )", PM should be able to show thed
>> user if he set USE="kontact", kde USE flag is enabled and the PM will
>> enable this USE flag by himself.
>
> Is the less expressive solution you're describing still useful enough
> to make it worthwhile? When we were doing this for Exherbo, we
> identified five types of inter-use-flag dependency:
>
> * if a then b
> * if a then not b
> * at least one of a b c, possibly only if d
> * exactly one of a b c, possibly only if d
> * at most one of a b c, possibly only if d
>
> Does Gentoo make use of all of these, and are there any cases that the
> above doesn't cover? How would you express each of the above using
> USE_REQUIREMENTS?
>
> From a package manager perspective, it's much easier to give good
> advice to the user if we're told by the ebuild exactly what's going on.

I've said this before, but maybe now the time is right.

I think that many of these issues are caused by use flags being binary which
causes the total number of options to be a power of 2. If the real total number
of options is not a pwoer of 2 then some combinations of use flags are a priori
bad and thus currently we try to work around this.
I propose that use flag are not merely binary flags, but can take a value out of
a range of possible values. Binary use flags could be `on' or `off'. Other use
flags could range over a wider range of values. We could then catch errors early
as "use flag $flag has bad value $badvalue".

> * if a then b

This means that the situation +a -b is bad. So going with the ekiga example
above, there could be a `kontact' use flag with possible values `off&-kde',
`off&+kde' and `on'. The same situation can also be modeled by a `kde' use flag
with possible values `on-with-kontact', `on-without-kontact', `off'.

> * if a then not b

Basically the same as above: +a +b is bad, so use flag `f' could range over
"a&-b" "-a&-b" "-a&b" and signal an error for any other value.

> * at least one of a b c, possibly only if d

I would be interested in knowing the specifics of packages wanting this. (It
could possibly be addressed by use flags that take a set of values simultaneously.)

> * exactly one of a b c, possibly only if d

There should be a use flag `d' with possible values in `a', `b', `c' and
possibly `off'. This is really the situation where my proposal shines. This
covers the situation where you need an implementation of $proglang but don't
care whether it is $progimpl-lolcat, $progimpl-fuzzycat, $progimpl-dog or any
one of a number of other supported implementations.

> * at most one of a b c, possibly only if d

This situation is equivalent to the situation:
* exactly one of `a' `b' `c' `none', possibly only if d which was solved above.

4 out of 5 ain't bad ;P

Marijn

- --
If you cannot read my mind, then listen to what I say.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqbq4YACgkQp/VmCx0OL2wyLQCgiZz5l+UyPEMc8Ci35C/muAmd
IZEAniGWrm52eWZTsyJUDGzVJjx8uRlH
=iieZ
-----END PGP SIGNATURE-----

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

volkmar at gentoo

Aug 31, 2009, 11:02 AM

Post #6 of 11 (596 views)

Permalink

Nirbheek Chauhan wrote:
> There's also bug 251179[1], which is ugly at first glance, but shows
> that we don't really need an extra variable to control dependencies
> between USE-flags (it *is* after all a dependency).
>
> So, we can either use
>
> use1? ( =${CATEGORY}/${PVR}[use2,use3,use4] )
>
> which will probably require less changes to portage's resolver; or
> something else like
>
> use1? ( use2 use3 use4 )
>
> The latter is unambiguous because it's not a package atom (no / ).
> Either of these will work great when portage gets automatic
> USE-dependency enabling.
>
Indeed, this is doable but I don't think it's clear enough. In addition,
speaking of PM, it will force it to be able to detect use1? ( use2 ) and
use1? ( cat/pkg ). Speaking of ebuild readability it's also not a good
thing because that's not real a dependency.
If needed, we can put this in IUSE variable actually. I've nothing
against even if I prefer IUSE_REQUIREMENTS because it's clearer: we
define IUSE vars somewhere and how to handle them somewhere else.

--
Mounir

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

volkmar at gentoo

Aug 31, 2009, 11:15 AM

Post #7 of 11 (582 views)

Permalink

Ciaran McCreesh wrote:
> Is the less expressive solution you're describing still useful enough
> to make it worthwhile? When we were doing this for Exherbo, we
> identified five types of inter-use-flag dependency:
>
Actually, I said in my email I was looking for opinions about the
feature not really about the syntax. It was just an example but as
no-one jump to say it was useless and stupid, let's try with a clearer
syntax.

> * if a then b
>
IUSE_REQUIREMENTS="a? ( b )"
> * if a then not b
>
IUSE_REQUIREMENTS="a? ( -b )"
> * at least one of a b c, possibly only if d
>
IUSE_REQUIREMENTS="d? ( || ( a b c ) )"
> * exactly one of a b c, possibly only if d
>
IUSE_REQUIREMENTS="d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c? (
-a -b )"
> * at most one of a b c, possibly only if d
>
IUSE_REQUIREMENTS="d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) )"
if needed we can add IUSE_REQUIREMENTS="!d? ( -a -b -c)"
> Does Gentoo make use of all of these, and are there any cases that the
> above doesn't cover? How would you express each of the above using
> USE_REQUIREMENTS?
>
> From a package manager perspective, it's much easier to give good
> advice to the user if we're told by the ebuild exactly what's going on.
>
So I think we can satisfy all use cases with the classic Gentoo syntax
even if new operators could be appreciated ;)

--
Mounir

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

ciaran.mccreesh at googlemail

Aug 31, 2009, 11:27 AM

Post #8 of 11 (581 views)

Permalink

On Mon, 31 Aug 2009 20:15:37 +0200
Mounir Lamouri <volkmar@gentoo.org> wrote:
> > * at least one of a b c, possibly only if d
> >
> IUSE_REQUIREMENTS="d? ( || ( a b c ) )"

Moderately eww...

> > * exactly one of a b c, possibly only if d
> >
> IUSE_REQUIREMENTS="d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c?
> ( -a -b )"

Really eww...

> > * at most one of a b c, possibly only if d
> >
> IUSE_REQUIREMENTS="d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) )"

Similarly eww.

> > From a package manager perspective, it's much easier to give good
> > advice to the user if we're told by the ebuild exactly what's going
> > on.
>
> So I think we can satisfy all use cases with the classic Gentoo syntax
> even if new operators could be appreciated ;)

How do we translate the above into nice friendly messages for the user?
Taking the "exactly one" case, it's much better to say to the user:

* If 'd' is enabled, exactly one of 'a', 'b' or 'c' must be enabled

Than:

* If 'd' is enabled, at least one of 'a', 'b' or 'bc' must be
enabled

Then when the user turns on all three:

* If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled
* If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled
* If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled
* If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled
* If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled
* If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled

And in the general case, there's no way of translating the latter into
the former.

Much easier for everyone if you just say what you mean rather than
converting it into some convoluted (but theoretically equivalent) less
expressive syntax.

--
Ciaran McCreesh

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

dev-random at mail

Aug 31, 2009, 1:49 PM

Post #9 of 11 (583 views)

Permalink

On Mon, Aug 31, 2009 at 07:27:32PM +0100, Ciaran McCreesh wrote:
> Then when the user turns on all three:
>
> * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled
> * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled
> * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled
> * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled
> * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled
> * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled
>
> And in the general case, there's no way of translating the latter into
> the former.
>
> Much easier for everyone if you just say what you mean rather than
> converting it into some convoluted (but theoretically equivalent) less
> expressive syntax.

I suggest alternative syntax, less powerfull but more expressive:
groups of use-flags.

Guess we define the following flags in IUSE:
3d.nvidia 3d.ati 3d.intel
or
3d+nvidia 3d+ati 3d+intel
or
3d:nvidia 3d:ati 3d:intel

In first case we may enable any number of those flags.
In second case we must enable at least one of them.
In third case we must enable exactly one of them.
In all 3 cases, if (and only if) flag '3d' itself exist in IUSE,
those flags are ignored when it is unset.

For convenience, user may use '.' as middle-character in config in
all 3 cases (or, perhaps, even omit it and everything before it),
but in output of PM he will see proper character and understand
dependencies between flags without any explanation in English.

If we add flag which depends on nvidia (e.g. cg), we name it
3d.nvidia.cg, and it will be ignored (perhaps with warning) if flag
3d.nvidia is unset.

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

volkmar at gentoo

Aug 31, 2009, 1:55 PM

Post #10 of 11 (586 views)

Permalink

Ciaran McCreesh wrote:
> On Mon, 31 Aug 2009 20:15:37 +0200
> Mounir Lamouri <volkmar@gentoo.org> wrote:
>
>>> * at least one of a b c, possibly only if d
>>>
>>>
>> IUSE_REQUIREMENTS="d? ( || ( a b c ) )"
>>
>
> Moderately eww...
>
>
>>> * exactly one of a b c, possibly only if d
>>>
>>>
>> IUSE_REQUIREMENTS="d? ( || ( a b c ) ) a ? ( -b -c ) b ? ( -a -c ) c?
>> ( -a -b )"
>>
>
> Really eww...
>
>
>>> * at most one of a b c, possibly only if d
>>>
>>>
>> IUSE_REQUIREMENTS="d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) )"
>>
>
> Similarly eww.
>
>
>>> From a package manager perspective, it's much easier to give good
>>> advice to the user if we're told by the ebuild exactly what's going
>>> on.
>>>
>> So I think we can satisfy all use cases with the classic Gentoo syntax
>> even if new operators could be appreciated ;)
>>
>
> How do we translate the above into nice friendly messages for the user?
> Taking the "exactly one" case, it's much better to say to the user:
>
> * If 'd' is enabled, exactly one of 'a', 'b' or 'c' must be enabled
>
> Than:
>
> * If 'd' is enabled, at least one of 'a', 'b' or 'bc' must be
> enabled
>
> Then when the user turns on all three:
>
> * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled
> * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled
> * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled
> * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled
> * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled
> * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled
>
> And in the general case, there's no way of translating the latter into
> the former.
>
> Much easier for everyone if you just say what you mean rather than
> converting it into some convoluted (but theoretically equivalent) less
> expressive syntax.
>
We don't see this feature the same way. I don't want to add a feature
that will prevent the maintainer to die if we can't found another way. I
want the package manager do make some decisions before calling the ebuild.

For example:
* if a then b
IUSE_REQUIREMENTS="a? ( b )"
if USE="-a b" is used, the package manager should enable a because it's
needed for b and it should show this. We could say we also can disable b
but we can't know if a USE flag is disabled or just not enabled (in
other words, because every USE flags is disabled by default). In
addition, we can consider if someone want to enable a feature it should
be more important than disabling another.

* if a then not b
IUSE_REQUIREMENTS="a? ( -b )"
if USE="a b", b should be disabled by the PM. It's up to the maintainer
to choose a default behavior by setting the relation between USE flags
(b? ( -a ) is equivalent but will disable a).

* at least one of a b c, possibly only if d
IUSE_REQUIREMENTS="d? ( || ( a b c ) )"
if USE="d", the PM will enable a.

* exactly one of a b c, possibly only if d
IUSE_REQUIREMENTS="d? ( || ( a b c ) ) a? ( -b -c ) b? ( -a -c ) c? ( -a
-b )"
if USE="d", same as before.
if USE="d a", nothing
if USE="d a b", it's harder because a? ( -b -c ) and b? ( -a -c ). We
can imagine to disable b because a is the first value in || ( a b c )
but it's not satisfying. We can imagine another operator like | to
represent this dependency: "d? ( | ( a b c ) )"

* at most one of a b c, possibly only if d
IUSE_REQUIREMENTS="d? ( a? ( -b -c) b? ( -a -c ) c? ( -a -b) )"
it's quite similar to the previous one but here it's harder to guess
which one should be keep if USE="d a b".
As previously, we can imagine another operator like "d? ( ||| ( a b c ) )"

But if we want to move to a really generic specification, we can
introduce something similar to Exherbos syntax:
exactly-N, max-N, min-N with N as a positive integer.
So, we could write:
"d? ( exactly-1? ( a b c ) )"
"d? ( max-1? ( a b c ) )"
"d? ( min-1? ( a b c ) )"
With this syntax, it's easy to consider first values as one to use by
default for the PM (so, never failing).

The only big issue I see with this syntax is it will make exactly-N,
max-N and min-N no valid USE flags. But we can prevent that by prefixing
the name by an illegal character like ||exactly-1.

About the dying thing, I just want to precise I don't want to add a
feature that will only die with a cool message. Maintainers can do that.
The idea is to prevent maintainers to do that without silently enabling
a feature or moving to an unstable state (because of EAPI-2 use
dependencies).
It will let maintainers to die if they want. They will not have to set
"a? ( b )" if they really think a shouldn't be enabled (even with
possible user knowledge) if b is enabled. In this case, the classic die
statement will be ok.

Thanks,
Mounir

Re: [RFC] USE flags requirements (EAPI-4 ?) [ In reply to ]

volkmar at gentoo

Aug 31, 2009, 2:15 PM

Post #11 of 11 (591 views)

Permalink

dev-random@mail.ru wrote:
> On Mon, Aug 31, 2009 at 07:27:32PM +0100, Ciaran McCreesh wrote:
>
>> Then when the user turns on all three:
>>
>> * If 'd' is enabled, if 'a' is enabled, 'b' must not be enabled
>> * If 'd' is enabled, if 'a' is enabled, 'c' must not be enabled
>> * If 'd' is enabled, if 'b' is enabled, 'a' must not be enabled
>> * If 'd' is enabled, if 'b' is enabled, 'c' must not be enabled
>> * If 'd' is enabled, if 'c' is enabled, 'a' must not be enabled
>> * If 'd' is enabled, if 'c' is enabled, 'b' must not be enabled
>>
>> And in the general case, there's no way of translating the latter into
>> the former.
>>
>> Much easier for everyone if you just say what you mean rather than
>> converting it into some convoluted (but theoretically equivalent) less
>> expressive syntax.
>>
>
> I suggest alternative syntax, less powerfull but more expressive:
> groups of use-flags.
>
> Guess we define the following flags in IUSE:
> 3d.nvidia 3d.ati 3d.intel
> or
> 3d+nvidia 3d+ati 3d+intel
> or
> 3d:nvidia 3d:ati 3d:intel
>
> In first case we may enable any number of those flags.
> In second case we must enable at least one of them.
> In third case we must enable exactly one of them.
> In all 3 cases, if (and only if) flag '3d' itself exist in IUSE,
> those flags are ignored when it is unset.
>
> For convenience, user may use '.' as middle-character in config in
> all 3 cases (or, perhaps, even omit it and everything before it),
> but in output of PM he will see proper character and understand
> dependencies between flags without any explanation in English.
>
> If we add flag which depends on nvidia (e.g. cg), we name it
> 3d.nvidia.cg, and it will be ignored (perhaps with warning) if flag
> 3d.nvidia is unset
As you said, it's not enough powerful. It's going to be hard if foo
flags depends on 3d and bar.
In addition, I don't think the real issues is the friendliness of the
syntax but the powerful aspect. Indeed, it shouldn't be shown to the
user and more the syntax is powerful less the user will be annoyed.

--
Mounir

Mailing List Archive

Attached Files:

Attached Files: