"Hemmann, Volker Armin" <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [email protected] mailing list
