Re: USE flags mumbling

[Richard Purdie <rpurdie@rpsys.net>]

On Fri, 2010-07-02 at 08:52 +0200, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 02-07-10 00:16, Tom Rini wrote:
> > Koen Kooi wrote:
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 01-07-10 18:24, Graeme Gregory wrote:
> >>> We already have BBCLASSEXTENDS which modifies ${PN} of a package and
> >>> can use overrides to change behaviors of recipes.
> >>>
> >>> Maybe USE flags could be implemented in a similar fashing.
> >>>
> >>> DISTRO_USE = "nossl nox11"
> >>>
> >>> EXTRA_OECONF_append_use-nossl = "--disable-ssl"
> >>>
> >>> ${PN} of the recipe becomes XXXX-nossl
> >>>
> >>> Thoughts?
> >>
> >> Just that USE flags shouldn't be used if seperate recipes can solve it
> >> as well.
> > 
> > If I may, I'd like to articulate what I believe to be the technical
> > argument behind this statement.
> > 
> > One of the issues with some form of USE flags, and I believe this is one
> > of the big ones for Angstrom as well as any other public feed publishing
> > distribution is that having a single recipe that does different things
> > based on variables makes maintaining their feed (and allowing users to
> > publish their own compatible feeds) a nightmare.
> 
> That's not what I'm getting at. If 2 *packages* can safely co-exist in
> the feeds *and* and image can choose which it wants to install USE flags
> artificially limit the choice.
> Example: opkg, nopkg-nopgp
> 
> This extends to things like "shadow or tinylogin?" as well.

Graeme suggested something like BBCLASSEXTEND for USE flags. I've also
wondered about it.

Any "USE" case contains at least three pieces of information:

a) Which configure flag we're playing with
b) What DEPENDS needs to change
c) Some kind of associated name for the flag

Creating an example, lets have a case where we have "ssl, x11, dbus,
bluez and wifi" as features. This example isn't so crazy as once we open
the box, someone will want every combination of every possible option.

With 5 options there are 32 different possible variants.

Now I realise not all combinations of "USE" cases work together or
actually make sense. Do we list the combinations that are allowed? or
disallowed?

By the time you delve into adding some complex configuration system to
merge together all this data, I'd suggest it makes a lot more sense to
have setups like opkg where we have a simple .inc file which does:

require foo_${PV}.bb

DEPENDS += "xyz"
EXTRA_OECONF = "--with-xyz"

and the addition of a -= operator in bitbake could be very useful.

BBCLASSEXTEND grew out of the shear number of recipes that followed a
form of just inheriting native. I'd suggest that if we need an extension
to bitbake in the future we can add one but lets make it work without
that, at least at first and see what makes sense.

I'd suggest that adding 32 different variants of a package just dilutes
our testing further and will become an unmaintainable nightmare so any
system which limits the number of variants to those we actually need is
desirable.

This whole discussion also doesn't get to how to select which
combination you actually want to use in an image. If you pull in
something with ssl enabled, you probably want to change to the ssl
versions of all the other packages with that option for example. This
implies that the package manager needs to be taught something about
this.

So that covers generating all the multiple outputs of USE cases. What
about users wishing to modify a given recipes flags without changing its
name? This is its own can of worms.

I'd point out you can already do fun things like:

EXTRA_OECONF_append_pn-opkg = " --without-ssl"

from your distro.conf or local.conf.

I don't really have a conclusion. In some cases providing multiple
variants makes sense. In others its just impractical and being able to
change the flags of packages does make sense for some people's usecases.
Regardless of what we do, it needs a lot of thought and planning going
into it and I don't think anyone has followed through the implications
to the level of detail required :/. It is a case where forward planning
would help a lot.

Cheers,

Richard