1 |
Jesús Guerrero <i92guboj@×××××.es> posted |
2 |
524cf6368e2642a1637e6e3054466e3d.squirrel@××××××××××××××××.org, excerpted |
3 |
below, on Tue, 07 Jul 2009 19:30:58 +0200: |
4 |
|
5 |
> On Tue, July 7, 2009 15:35, Gilles Dartiguelongue wrote: |
6 |
>> Le mardi 07 juillet 2009 à 13:57 +0100, AllenJB a écrit : [snip] |
7 |
>> |
8 |
>>> Are users really going to want to fine-tune between just playing or |
9 |
>>> also being able to rip/write audio cd's? |
10 |
>> |
11 |
>> I myself would probably not separate those features but they might be |
12 |
>> because they pull a number of different libs. |
13 |
|
14 |
> Ripping a cd just requires raw access to the device. |
15 |
|
16 |
> Playing cdaudio requires a lot more stuff, besides many other thing it |
17 |
> will require a working sound system |
18 |
|
19 |
> You might use a computer to rip cdaudio to fill your portable mp3 player |
20 |
> or to do backups, that doesn't mean that you want alsa in that machine, |
21 |
> you might not even have speakers attached. |
22 |
|
23 |
>> Getting informations from cddb or musicbrainz is another story |
24 |
>> and I wouldn't like to see this notion merged with cdaudio. |
25 |
|
26 |
> cddb must stay as it is, there's no reason to change that. |
27 |
|
28 |
> Whether you pick cdda, cdaudio or audiocd is completely unimportant to |
29 |
> me, the other two functionalities shouldn't have anything to do with |
30 |
> this. |
31 |
|
32 |
I don't really care whether the flags are merged or not, but what I'd |
33 |
DEFINITELY find useful is per-package metadata on what the flag actually |
34 |
does for that package. |
35 |
|
36 |
If that means splitting flags down a bit, so the metadata is in the USE |
37 |
flag itself (paranoia: paranoia support, cdda: cdda support, cdripping: |
38 |
ripping support, alsa: alsa support, etc), great. |
39 |
|
40 |
If it means it's just one big cdaudio flag, but each package has its own |
41 |
metadata saying what it actually does with it, that's great too. |
42 |
However, that'll mean a big change from today, as few packages have that |
43 |
detailed metadata on what their USE flags actually do. |
44 |
|
45 |
While we're at it, getting user-visible documentation on flag conflicts |
46 |
would be nice, too. (also OR oss flag, if both are enabled, alsa is the |
47 |
default, that type of comment in the metadata.) |
48 |
|
49 |
It's frustrating and time consuming to have to dig into the ebuild code |
50 |
itself to see what the dependency/support actually is, or even worse, to |
51 |
have to dig into the package code or README/INSTALL files to get that |
52 |
info. |
53 |
|
54 |
How many times have I seen a USE flag and asked myself, OK, but what does |
55 |
that actually MEAN, in terms of dependencies, etc? |
56 |
|
57 |
An unrelated but good example of that is USE=doc. Fortunately, there's a |
58 |
number of packages that have local descriptions. But it's way too few |
59 |
compared to those that have it in IUSE but don't explain what it actually |
60 |
means in the package. Is it huge dependencies, huge build-times, huge |
61 |
size, simply unnecessary for the user, or a combination, if it's a |
62 |
combination, which, and if it's dependencies, which ones? (This one is |
63 |
at the top of my mind ATM due to the recent but now corrected USE=doc |
64 |
abuse for kde4. Thanks, kde team, for fixing that. It was very |
65 |
frustrating, but I realize the Gentoo packages were still in the heavy |
66 |
development and experimentation stage.) |
67 |
|
68 |
-- |
69 |
Duncan - List replies preferred. No HTML msgs. |
70 |
"Every nonfree program has a lord, a master -- |
71 |
and if you use the program, he is your master." Richard Stallman |