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: [EMAIL PROTECTED] Weblog: http://planet.gentoo.org/developers/leio
signature.asc
Description: This is a digitally signed message part
