Steve Long <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], 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 -- [EMAIL PROTECTED] mailing list
