[gentoo-dev] Re: lame use flag, local to global

[Duncan]

Steve Long <slong@××××××××××××××××××.uk> posted
fen3qr$lu6$1@×××××××××.org, excerpted below, on  Fri, 12 Oct 2007 07:26:12
+0100:

>> In that case, shouldn't the description mention that?  Something like:
>>
>> MP3 encoding support using LAME (as opposed to ffmpeg)
>>
> What about when the next one gets added-- would it need to say "as
> opposed to ffmpeg or lame"?

Good point.  However, my minor complaint with USE flags is that they too 
often don't really say what the USE flag actually does.  In this case as-
is, the implication is that with -lame, there's no encoding support, when 
the general case is that there's still encoding support, but from 
something else (ffmpeg).  Ideally, the description isn't so vague as to 
leave the user with the wrong impression, or having to dig into the 
ebuild itself to find out what the practical effect is.

So something like:

Support LAME as mp3 encoder (see ffmpeg also)

Then ideally, if a package supported both encoders, both would be flags, 
and if possible, support for both would be built if both USE flags were 
enabled.  That's a bit more expandable, altho it still mentions ffmpeg.

Making it generic "(other encoders may also be supported)" might be 
better in some ways, but isn't as helpful in others.  IMO, the ffmpeg 
reference is more helpful, and the mention of ffmpeg could be expanded if 
other options become popular enough to warrant it.


What I'd /really/ like would be a simple way to list what each flag does 
in a particular package, sort of like what use.local sometimes does now, 
if the description is specific enough, but for global flags as well.  
Take USE=perl.  Sure, it supports perl, but is it perl bindings, or 
additional user scripts in perl, or documentation for perl devs, or ???  
A use.local.desc (or whatever) file listing every package with the flag, 
and what the flag actually does in that package in practical terms, would 
sure be useful! =8^)  Of course, being a separate file, it'd be difficult 
to keep up to date.  Perhaps a better solution might be an IUSE_DESC 
variable that every ebuild and eclass could (and would eventually be 
required to) populate.  Then it's metadata for the package kept right in 
the ebuild/eclass, where it's easy to keep up to date when the package 
itself changes.  Then all we'd need would be a parsing tool for that 
info... euse could be expanded to grab it if --verbose is set, perhaps, 
and life would be /so/ much easier, at least for /some/ users. =8^)

Yes, I know the chances of it happening would be better if I were to 
become a dev and volunteer to help with all the updates, since it's my 
itch I want scratched.  Maybe it'll happen someday.  In the mean time... 
maybe I can spread the itch. =8^)

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