Jesús Guerrero <i92gu...@terra.es> posted 524cf6368e2642a1637e6e3054466e3d.squir...@jesgue.homelinux.org, excerpted below, on Tue, 07 Jul 2009 19:30:58 +0200:
> On Tue, July 7, 2009 15:35, Gilles Dartiguelongue wrote: >> Le mardi 07 juillet 2009 à 13:57 +0100, AllenJB a écrit : [snip] >> >>> Are users really going to want to fine-tune between just playing or >>> also being able to rip/write audio cd's? >> >> I myself would probably not separate those features but they might be >> because they pull a number of different libs. > Ripping a cd just requires raw access to the device. > Playing cdaudio requires a lot more stuff, besides many other thing it > will require a working sound system > You might use a computer to rip cdaudio to fill your portable mp3 player > or to do backups, that doesn't mean that you want alsa in that machine, > you might not even have speakers attached. >> Getting informations from cddb or musicbrainz is another story >> and I wouldn't like to see this notion merged with cdaudio. > cddb must stay as it is, there's no reason to change that. > Whether you pick cdda, cdaudio or audiocd is completely unimportant to > me, the other two functionalities shouldn't have anything to do with > this. I don't really care whether the flags are merged or not, but what I'd DEFINITELY find useful is per-package metadata on what the flag actually does for that package. If that means splitting flags down a bit, so the metadata is in the USE flag itself (paranoia: paranoia support, cdda: cdda support, cdripping: ripping support, alsa: alsa support, etc), great. If it means it's just one big cdaudio flag, but each package has its own metadata saying what it actually does with it, that's great too. However, that'll mean a big change from today, as few packages have that detailed metadata on what their USE flags actually do. While we're at it, getting user-visible documentation on flag conflicts would be nice, too. (also OR oss flag, if both are enabled, alsa is the default, that type of comment in the metadata.) It's frustrating and time consuming to have to dig into the ebuild code itself to see what the dependency/support actually is, or even worse, to have to dig into the package code or README/INSTALL files to get that info. How many times have I seen a USE flag and asked myself, OK, but what does that actually MEAN, in terms of dependencies, etc? An unrelated but good example of that is USE=doc. Fortunately, there's a number of packages that have local descriptions. But it's way too few compared to those that have it in IUSE but don't explain what it actually means in the package. Is it huge dependencies, huge build-times, huge size, simply unnecessary for the user, or a combination, if it's a combination, which, and if it's dependencies, which ones? (This one is at the top of my mind ATM due to the recent but now corrected USE=doc abuse for kde4. Thanks, kde team, for fixing that. It was very frustrating, but I realize the Gentoo packages were still in the heavy development and experimentation stage.) -- 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
