[gentoo-dev] Policy for conflicting USE flags

[gentoo-dev] Policy for conflicting USE flags

[Ulrich Mueller]

EAPI 4 introduced the REQUIRED_USE variable, which allows to impose
restrictions on the allowed USE flag combinations for an ebuild.

On the other hand, according to the devmanual, our policy on
conflicting USE flags is as follows:

| <http://devmanual.gentoo.org/general-concepts/use-flags/#conflicting-use-flags>
| Occasionally, ebuilds will have conflicting USE flags for
| functionality. Checking for them and returning an error is not a
| viable solution. Instead, you must pick one of the USE flags in
| conflict to favour and should alert the user that a particular flag
| is being used instead.

Is this policy still valid, which would imply that REQUIRED_USE
should be used only sparingly? Or should it be used in all cases of
conflicting flags?

As an example for the two extreme cases, the app-editors/emacs-23.2-r3
ebuild currently has only the following minimal solution:

   REQUIRED_USE="aqua? ( !X )"

Whereas with taking account of all conflicts, it would look like this:

   REQUIRED_USE="
	alsa? ( sound )
	X? (
		!aqua
		m17n-lib? ( xft )
		^^ (
			gtk
			motif
			Xaw3d
			( !gtk !motif !Xaw3d )
		)
		toolkit-scroll-bars? ( || ( gtk motif Xaw3d ) )
	)
	!X? (
		!gconf
		!gif
		!gtk
		!imagemagick
		!jpeg
		!libxml
		!m17n-lib
		!motif
		!png
		!svg
		!tiff
		!toolkit-scroll-bars
		!Xaw3d
		!xft
		!xpm
	)"

If we really implemented it in this way, then I fear that it would be
difficult for users to find out what flag combinations they can use.
(As was pointed out in bug 347353, it is a satisfiability problem,
which in the general case is NP-complete ...)

Some possible middle ground would block only combinations that lead
to surprising results for the user. (Using the above example again,
one would allow only one of "gtk", "Xaw3d", and "motif". But with
USE="-X", one would simply ignore flags like "png" or "jpeg", because
it can't be surprising that images can't be displayed without X.)

So, what policy should we follow here?

Ulrich

[gentoo-dev] Re: Policy for conflicting USE flags

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 2981 bytes --]

On Tue, 8 Feb 2011 22:29:11 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> EAPI 4 introduced the REQUIRED_USE variable, which allows to impose
> restrictions on the allowed USE flag combinations for an ebuild.
> 
> On the other hand, according to the devmanual, our policy on
> conflicting USE flags is as follows:
> 
> | <http://devmanual.gentoo.org/general-concepts/use-flags/#conflicting-use-flags>
> | Occasionally, ebuilds will have conflicting USE flags for
> | functionality. Checking for them and returning an error is not a
> | viable solution. Instead, you must pick one of the USE flags in
> | conflict to favour and should alert the user that a particular flag
> | is being used instead.
> 
> Is this policy still valid, which would imply that REQUIRED_USE
> should be used only sparingly? Or should it be used in all cases of
> conflicting flags?
> 
> As an example for the two extreme cases, the app-editors/emacs-23.2-r3
> ebuild currently has only the following minimal solution:
> 
>    REQUIRED_USE="aqua? ( !X )"
> 
> Whereas with taking account of all conflicts, it would look like this:
> 
>    REQUIRED_USE="
> 	alsa? ( sound )
> 	X? (
> 		!aqua
> 		m17n-lib? ( xft )
> 		^^ (
> 			gtk
> 			motif
> 			Xaw3d
> 			( !gtk !motif !Xaw3d )
> 		)
> 		toolkit-scroll-bars? ( || ( gtk motif Xaw3d ) )
> 	)
> 	!X? (
> 		!gconf
> 		!gif
> 		!gtk
> 		!imagemagick
> 		!jpeg
> 		!libxml
> 		!m17n-lib
> 		!motif
> 		!png
> 		!svg
> 		!tiff
> 		!toolkit-scroll-bars
> 		!Xaw3d
> 		!xft
> 		!xpm
> 	)"
> 
> If we really implemented it in this way, then I fear that it would be
> difficult for users to find out what flag combinations they can use.
> (As was pointed out in bug 347353, it is a satisfiability problem,
> which in the general case is NP-complete ...)
> 
> Some possible middle ground would block only combinations that lead
> to surprising results for the user. (Using the above example again,
> one would allow only one of "gtk", "Xaw3d", and "motif". But with
> USE="-X", one would simply ignore flags like "png" or "jpeg", because
> it can't be surprising that images can't be displayed without X.)
> 
> So, what policy should we follow here?

The guideline I usually follow is that flags depending on another flag being
set (eg. png needs X) should be ignored (you can always ewarn).  For flags
that conflict with other flags (exactly one of many, if-this-not-this) use
REQUIRED_USE.  Does that make sense?

If we went with your second extreme, if I wanted to disable X for emacs, I'd
also have to add 10 additional flags to package.use on my system to get it to
work.  If we were doing that for every package I'd switch distros.


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Policy for conflicting USE flags

[Ulrich Mueller]

>>>>> On Tue, 8 Feb 2011, Ryan Hill wrote:

>> If we really implemented it in this way, then I fear that it would
>> be difficult for users to find out what flag combinations they can
>> use.

> The guideline I usually follow is that flags depending on another
> flag being set (eg. png needs X) should be ignored (you can always
> ewarn). For flags that conflict with other flags (exactly one of
> many, if-this-not-this) use REQUIRED_USE. Does that make sense?

Yes, in my opinion it does. Should the devmanual be updated
accordingly? (There is already bug 353624 open for it.)

Maybe we also need a guideline that whenever possible, ebuilds should
accept the default USE flags from our profiles as a valid combination?
Or, in the exceptional case when that isn't possible, a package.use
entry should be added to profiles.

> If we went with your second extreme, if I wanted to disable X for
> emacs, I'd also have to add 10 additional flags to package.use on my
> system to get it to work. If we were doing that for every package
> I'd switch distros.

That's what I thought too. ;-)

In other words: If an ebuild has n USE flags and the package can be
configured in m different ways, then it is _not_ the goal to allow
only m of the 2**n possible flag combinations.

Ulrich

Re: [gentoo-dev] Re: Policy for conflicting USE flags

[Zac Medico]

On 02/08/2011 06:20 PM, Ryan Hill wrote:
> The guideline I usually follow is that flags depending on another flag being
> set (eg. png needs X) should be ignored (you can always ewarn).  For flags
> that conflict with other flags (exactly one of many, if-this-not-this) use
> REQUIRED_USE.  Does that make sense?

In order to try to avoid forcing users to micro-manage flags too much,
it might make sense to avoid REQUIRED_USE whenever it's possible to do a
build that will almost certainly suit the user's needs. The most common
case that I can imagine where REQUIRED_USE is really necessary is for
libraries were reverse USE dependencies might be broken without it.
-- 
Thanks,
Zac

[gentoo-dev] Re: Policy for conflicting USE flags

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 945 bytes --]

On Wed, 9 Feb 2011 13:04:11 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> Maybe we also need a guideline that whenever possible, ebuilds should
> accept the default USE flags from our profiles as a valid combination?
> Or, in the exceptional case when that isn't possible, a package.use
> entry should be added to profiles.

Yes, we need to be careful when using REQUIRED_USE with global USE flags,
especially the defaults.  If a new user has to spend half an hour trying to
figure out the magic combination of USE flags that will allow them to run
`emerge @world` on their fresh install they're going to get frustrated and
leave.

I imagine it would break stage building as well (?)


-- 
fonts, gcc-porting,                  it makes no sense how it makes no sense
toolchain, wxwidgets                           but i'll take it free anytime
@ gentoo.org                EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: Policy for conflicting USE flags

[Zac Medico]

On 02/09/2011 03:11 PM, Zac Medico wrote:
> In order to try to avoid forcing users to micro-manage flags too much,
> it might make sense to avoid REQUIRED_USE whenever it's possible to do a
> build that will almost certainly suit the user's needs. The most common
> case that I can imagine where REQUIRED_USE is really necessary is for
> libraries were reverse USE dependencies might be broken without it.

To clarify about issues with reverse USE dependencies, I mean  any
library with something like REQUIRED_USE="^^ ( a b )" where either a or
b would be specified in reverse USE dependencies.  Also, it's worth
noting that something like REQUIRED_USE="c? ( ^^ ( a b ) )" may not need
REQUIRED_USE if reverse USE dependencies dep on c rather than a or b.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: Policy for conflicting USE flags

[Jorge Manuel B. S. Vicetto]

On Thu, 10 Feb 2011, Ryan Hill wrote:

> On Wed, 9 Feb 2011 13:04:11 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>> Maybe we also need a guideline that whenever possible, ebuilds should
>> accept the default USE flags from our profiles as a valid combination?
>> Or, in the exceptional case when that isn't possible, a package.use
>> entry should be added to profiles.
>
> Yes, we need to be careful when using REQUIRED_USE with global USE flags,
> especially the defaults.  If a new user has to spend half an hour trying to
> figure out the magic combination of USE flags that will allow them to run
> `emerge @world` on their fresh install they're going to get frustrated and
> leave.
>
> I imagine it would break stage building as well (?)

The stage building process is affected by ebuilds that die for 
conflicting and or missing use flags. Fortunately, stage building only 
builds packages in the system set and not the world set.
So if you have a package in the system set, before you make it die in the 
above scenario, be sure to check with releng the impact and try to provide 
an "exception" for USE="build".

---
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng