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

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@××××××××××××.de> posted
200608131856.11003.volker.armin.hemmann@××××××××××××.de, excerpted below,
on  Sun, 13 Aug 2006 18:56:10 +0200:

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

You mean like this?

$grep avahi use.local.desc
gnome-base/gnome-vfs:avahi - Support for avahi mdns daemon.
media-sound/mt-daapd:avahi - Use avahi instead of howl as mdns daemon
media-sound/pulseaudio:avahi - Use avahi instead of howl as mdns daemon
media-sound/rhythmbox:avahi - support for avahi mdns daemon
media-video/vlc:avahi - Support for avahi mdns daemon.
net-dns/avahi:bookmarks - Install the avahi-bookmarks application (requires dev-python/twisted)
net-dns/avahi:howl-compat - Enable compat libraries for howl
net-dns/avahi:mdnsresponder-compat - Enable compat libraries for mDNSResponder
net-im/ekiga:avahi - Support for the avahi mdns daemon
net-im/gaim:avahi - Enable using avahi howl libraries.
net-misc/vino:avahi - Build with avahi support
sys-auth/nss-mdns:avahi - enable support for Avahi
$grep audacious use.local.desc
app-admin/conky:audacious - enable monitoring of audio tracks that are playing (media-sound/audacious)
app-emulation/uade:audacious - Enables support for media-sound/audacious
media-sound/audacious:chardet - Character set detection support for non-compliant ID3 tags
media-sound/audacious:modplug - Build with modplug support
media-sound/audacious:musepack - Build with musepack support
media-sound/audacious:sid - Build with SID (Commodore 64 Audio) support
media-sound/audacious:timidity - Build with Timidity++ (MIDI sequencer) support
media-sound/audacious:wma - Build with WMA (Windows Media Audio) support
net-irc/xchat-xsys:audacious - Enables Audacious (media player) integration

Those are local USE flags, not global.  What I'm proposing is similar
per-package detail for global USE flags as well.
 
> for local flags it is already done - and global flags... is such an
> amount of information really needed?

Arguably, yes.  If I know what the USE flag enables, both in terms of
dependencies and in terms of per-package functionality (not always the
same thing, see below), I can make a better per-package choice as to
whether I want the flag enabled for that package or not.
 
> If I have perl installed, why should I not want perl bindings, perl
> documentation and perl support in a package?

Because they are three different things.  If you don't know perl yourself,
you have no use for where the flag enables perl documentation and
examples, but could very well have a use for the documentation built using
perl for an otherwise non-perl related package.  The flip could also be
the case -- you want the perl docs, but have no interest in the extra docs
for some package you aren't actually developing with, just using, anyway. 
Both of those are totally separate from perl bindings, which again, might
be needed for something totally unrelated to you actually knowing how to
program perl, or wanting the docs built using perl for some other package
you just use in a pre-built script.


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

No, you /can't/ just look in the ebuild, because as I already said, the
ebuild simply says it uses libgnome, not /why/ it uses libgnome.  Perhaps
you want to be able to configure what browser it uses separately from the
browser you configure for the rest of gnome.  Knowing that's the /only/
thing the gnome support does, you might not want to build it in,
particularly when doing so means if your libgnome ever goes haywire, so
does pan.  If the added functionality is so minor, and you've had issues
with gnome before, there's a case to be made for not wanting to take that
risk.  However, you gotta /know/ that's all it does, before you can make
that informed choice. 

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

See, that's why I suggested keeping use.desc essentially as it is. 
Newbies and those who don't want the extra information then don't have to
deal with it.  When someone like me comes along that wants to know exactly
what a particular flag does in a package, the (separate) per-package
description file would be there to be used.

The idea is that people that want the brief description use one file,
those that want the details use the other, so everybody gets what they
want/need.

(As for the "insane" thing, I /did/ catch your meaning and didn't take
offense, so no problem here.  However, I know from experience how hard it
can be to apologize, as it's something I've had to work on, so thanks for
catching the potential before it even had a chance to blow up worse. Too
bad not everybody is as willing or quick with misunderstandings. Too many
time's I've seen good people driven away, because both sides refused to
back down over something pretty petty, all in all.)

-- 
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@g.o mailing list