[gentoo-amd64] Re: Re: Re: recommended USE flags

["Duncan" <1i5t5.duncan@cox.net>]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200608122218.22034.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sat, 12 Aug 2006 22:18:21 +0200:

> On Saturday 12 August 2006 20:35, Duncan wrote:
>> Peter Humphrey <prh@gotadsl.co.uk> posted
>> 200608121835.43684.prh@gotadsl.co.uk, excerpted below, on  Sat, 12 Aug
>>
>> > I disagree. It's easy enough for use.desc to say "This will pull in the
>> > whole X-Window System" or "Enables programs to handle WMF files". Or even
>> > just to include a single-letter G or L prefix to each description as a
>> > first step.
>>
>> But the thing is, different packages may do different things with a USE
>> flag.  Support for X is often linking against xlib (as in the example I
>> gave), but doesn't have to be that major, and (again as in the example)
>> could be a minor as adding a few icons and *.desktop files.  The only way
>> to describe the effect of a USE flag on each package, in many cases, is to
>> do just that, make the description per package, not global.
> 
> so instead of a short but useful hint, which is enough in 95% of cases,  
> concentrated in two files, you want the user to search all packages and read 
> thousands of descriptions just to figure out if he wants the flag or not?
> 
> Are you insane?

Well, maybe =8^P, but I don't seem to be conveying what I'm trying to say
accurately.  No, I'm NOT saying search all packages and read thousands of
descriptions (and agree, that could be considered insane, tho it's more or
less what one has to do now)...

> Oh, and for local-flags, there are several descriptions, have a look at ufed. 
> For the global ones 'pulls in X' or 'needed for mp3/wmv/avi support' is 
> really enough to know.It does not matter, that the single package does. I 
> want them to have wmv/mp3/X support, how they are do it, is the ebuild's 
> problem, not mine. I set a flag, the ebuild maintainer has to figure out how 
> to react to it.

What I'm suggesting is that use.desc stay more or less as it is, with a
general description for global USE flags.  However, instead of
use.local.desc only having non-global USE flags, have it list all flags
(or split it into two or more files if it gets unmanageably huge) for all
packages, with what they do for that package.

For a quick idea of what the USE flag does in general, then, if it's a
global USE flag, one would check the entry in use.desc which would be
much as it is now. For a better idea of what it does in a particular
package, check the corresponding entry in use.local.desc, which would
describe the effects of the flag on that particular package. That's what
I'm proposing.  Users could just check the general description if that's
all they wanted/needed, and have exactly the same level of info they have
now, with a possible tweak to a description here or there.  If they wanted
to know for example what the gnome flag did in the pan package, however,
they'd look in use.local.desc and see something to the effect of "Builds
against libgnome to let pan use the configured gnome browser."

See, the problem is that a flag, while it generally adds support for
<flagfeature>, can mean very different things in different ebuilds.  An
example is the perl flag.  In some ebuilds, it means build perl bindings. 
In others, it means install documentation for use with perl.  In still
others, it controls building optional package documentation that requires
perl to build -- documentation for the package, not for using it with
perl, but requiring perl to build that documentation.  Those are three
VERY different meanings, applying to different packages, with USE=perl
used to control them.  Having a per-package entry would allow the user to
see precisely which of these the perl flag was used for in a particular
package, or if it was used for something else entirely.  There's simply no
way to convey that with a global description, unless you effectively
include the per-package descriptions right in the global description, of
course making it long enough to do so, which would then leave us without a
way to get a short and concise general description whet that's all that's
needed.

Still think it's insane, or did I actually convey the idea in a way that
makes a bit more sense, now (whether you agree with it or not)? =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list