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

On Sunday 13 August 2006 12:20, Duncan wrote:

>
> > 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."

but we already have that!

Start ufed. Read some of the flag descriptions. For a lot of them, there are 
several ones.

avahi has since descriptions - for six different packages, or atm, two 
descriptions, audacious, three... for each package a different one.


>
> 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^)

for local flags it is already done - and global flags... is such an amount of 
information really needed?

If I have perl installed, why should I not want perl bindings, perl 
documentation and perl support in a package? Or pan - if I have gnome 
installed, why should I deactivate gnome support? 'It has gnome support, 
fine' why should I need more information? And if I really need to know, what 
gnome support means, I can always look into the ebuild.

Lots of information is a nice thing, but too much of it is not good either. 
Struck dead by the amount of information... (Er wurde von der Last des 
Wissens erschlagen.) it can happen, and it does happen. ufeds informations 
are already on the verge of getting to much - removing some here and there 
would be helpfull (like three of the 6 avahi comments), because you won't get 
to the end, if you have to read all of it.
-- 
gentoo-amd64@g.o mailing list