Re: [gentoo-dev] Re: Global USE flags (Was: mplayer global use flag)

[Mart Raudsepp]

On Sat, 2006-10-28 at 17:12 -0400, Alec Warner wrote:
> Caleb Cushing wrote:
> >>
> >> cairo and openexr, good idea, AFAIK.  udev has come up before but from
> >> that discussion, the flag means slightly different things in some cases.
> >> Keeping it local allows individual per-pkg descriptions, so where it
> >> means
> >> something different, the description can say so.  In both meanings, udev
> >> defaulting to on remained best, but with the slightly different
> >> meanings...
> >> There was some discussion about modifying things or changing the flag
> >> where it meant something else, but I don't know what came of that.
> >>
> >
> > maybe it would be a lot of work. to even develop the tools. but it
> > would be nice if a global use flag could have a detailed option.
> >
> > example.
> >
> > euse -i mplayer
> > [+ C  ] mplayer - Enable mplayer support for playback or encoding
> >
> > is what we currently get.
> >
> > add a -d option for --descriptive
> > euse -id mplayer could show something like
> > [+ C  ] mplayer - Enable mplayer support for playback or encoding
> >    media-video/kmplayer - adds the ability to play back media using
> > the mplayer engine
> >
> > or maybe something better...
>
> I don't think any specification precludes having a more descriptive
> per-package meaning.  It would just be a matter of:
>
> a.  having devs write them in use.local.desc when necessary
> b.  Having tools look in use.local.desc first.
>
> But the whole point of global flags is really to consolidate the
> description functions and keep naming consistent.  So I doubt (a) will
> ever come to pass for the majority of flags.  Luckily (a) isn't a hard
> requirement, tools don't loose functionality by looking in
> use.local.desc first.

The main problem in my eyes here is that with certain USE flags, the
description doesn't really convey what the user will get.
Many are in the form of "adds support for this optional thing" instead
of "by using this optional dependency [named often the same as the USE
flag name] you will get this and that extra functionality".


Now what good wxGTK maintainer would I be, if I didn't pick wxwindows
USE flag as an example:

"wxwindows - Adds support for wxWindows/wxGTK GUI toolkit"

Lets see what the user really gets with this in the example of a few
packages that use this USE flag in IUSE:

app-backup/bacula: a wxWidgets console, while there are other consoles
available, such as gnome2-console and having both USE flags will result
in two consoles. However all of these are dependent on bacule-console
local USE flag...

app-emulation-bochs: Compile a wxWidgets based GUI (other are available)
media-gfx/zphoto: Use wxWidgets for GUI (to get ANY kind of GUI)
media-video/gpac: Build wxOsmo4 and V4Studio
media-video/mkvtoolnix: Build mmg and a GUI for mkvinfo

All of these "support wxGTK" in the sense that they pull it in and build
a few things against it, but it doesn't articulate what does the user
exactly get from using that global USE flag for this particular package.
Sometimes she gets just some little extra GUI apps, sometimes a GUI in
the first place, sometimes an extra GUI interface in addition to others,
and so on.
Similar things can be observed with many other global USE flags (and
also some local flags) - examples on request (time consuming detail
gathering).

And that's the problem - the user doesn't know what benefit will it
bring her to use or not use a global USE flag for this particular
package.

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@g.o
Weblog: http://planet.gentoo.org/developers/leio