We need an entry in /usr/portage/profiles/use.local.desc to explain what the bindist flag actually does for this package. Reproducible: Always Steps to Reproduce: equery u ffmpeg (with >=app-portage/gentoolkit-0.3) Actual Results: * Found these USE flags for media-video/ffmpeg-0.6_p25767: U I [...] - - amr : Enables Adaptive Multi-Rate Audio support - - bindist : Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues) + + bzip2 : Use the bzlib compression library [...] Expected Results: An explanation that (apparently) one must enable bindist to allow faac support.
# USE="bindist faac" emerge -pv =ffmpeg-0.10.4 [...] The following REQUIRED_USE flag constraints are unsatisfied: bindist? ( encode? ( !faac !aacplus ) ) # -> it is imho self-explanatory, closing as worksforme
Seriously? It was so self-explanatory, I apparently got it wrong: you must DISable bindist to use faac. (It's been so long since my original report, the version of ffmpeg I was looking at isn't even in the tree anymore, but I assume I was looking at the ebuild to see what bindist did. I guess I either misread or mistyped.) In any case, how difficult is it to just clarify the situation in a local USE flag description? That's why 'use.local.desc' exists, isn't it? So people don't have to parse the raw ebuild code to find out what a USE flag does?
(In reply to comment #2) > Seriously? It was so self-explanatory, I apparently got it wrong: you must > DISable bindist to use faac. (It's been so long since my original report, > the version of ffmpeg I was looking at isn't even in the tree anymore, but I > assume I was looking at the ebuild to see what bindist did. I guess I either > misread or mistyped.) REQUIRED_USE probably didnt exist when you filled that bug. > In any case, how difficult is it to just clarify the situation in a local > USE flag description? That's why 'use.local.desc' exists, isn't it? So > people don't have to parse the raw ebuild code to find out what a USE flag > does? It is not difficult but rather useless and pointless to duplicate information in a local useflag. So is ranting and reopening this bug without understanding what has changed. You probably didnt even try USE="bindist faac" emerge ffmpeg before doing so...
We have tools like equery for a reason. Not everyone will try 'emerge -pv' with every combination of USE flags they might possible want to consider for a package, nor should they have to. 'equery u' should give useful information. Period. Sometimes I wonder why I even try....
BTW, see these similar resolved bugs in which developers thought it important enough to actually fix the problem: bug 369255, bug 369247, bug 369245, bug 369243, bug 369257. And if anything, this should have been closed "WONTFIX", not "WORKSFORME", since the bug as originally reported does actually exist, as everyone can clearly verify by following the steps I outlined.
(In reply to comment #4) > We have tools like equery for a reason. Not everyone will try 'emerge -pv' > with every combination of USE flags they might possible want to consider for > a package, nor should they have to. 'equery u' should give useful > information. Period. bindist : Flag to enable or disable options for prebuilt (GRP) packages (eg. due to licensing issues) you want to distribute a binary -> USE=bindist. it rants because you also want faac and its license is incompatible with ffmpeg -> disable faac. if it lets you emerge because you already have the good use combination -> you dont even need to know the details of ffmpeg's bindist useflag. I consider it enough babysitting and actually better than requiring everyone to read local descriptions of the bindist useflag of every single package :) Note: the consequences of 'bindist' in ffmpeg has changed in the past and will probably change in the future. How do you solve that ? REQUIRED_USE is per-ebuild so is well suited for this. use.local.desc will require either to keep the version information duplicated there or provide inacurate information. (In reply to comment #5) > And if anything, this should have been closed "WONTFIX", not "WORKSFORME", > since the bug as originally reported does actually exist, as everyone can > clearly verify by following the steps I outlined. WORKSFORME is rather because you are right: bindist was missing some information and silently disabling options. The problem is fixed and the solution implemented some time ago is different from the one you proposed.
Obviously this isn't going anywhere, but I'd like to point out that you continue to respond as if the bug is in the output of emerge. It is not. emerge has nothing to do with this. The bug is in the output of 'equery u' and any similar tools (that give the meanings of local USE flags). Many users _do_ want to check out what the various USE flags do before they emerge something, especially for the first time. AFAIK, no one relies on emerge to actually tell them what USE flags do. Instead, they use 'equery u' or some equivalent tool (euse, quse). Developers should allow users to do this by providing them the requisite information in the right places -- in this case, in 'use.desc' and/or 'use.local.desc'. If this is not true anymore, I certainly didn't get the memo... As indicated in my original report, the information on 'bindist' in 'use.desc' is completely useless, since it could literally do _anything_ in any particular package. (In freetype, for example, it used to enable or disable the "TrueType bytecode interpreter". Now the 'auto-hinter' flag is used instead.) To me, this means that bindist is simply a bad idea that should be avoided if at all possible. If it must be used, developers should at least have the courtesy to define what it does, in plain English, in 'use.local.desc' (as several have already done when it was pointed out to them). If describing the flag in 'use.local.desc' is impractical because the meaning can change radically from ebuild to ebuild, then that tells me you shouldn't be using that flag in the first place. Use a different flag, with a name that indicates, to some extent, what is actually being done. But, hey, what do I know? OK, I'm finished.
You misunderstood it seems: bindist description is correct; the useflag does what it says, that is, it disables/disallows stuff not suitable for binary distribution. In the case of ffmpeg, those 'non binary redistributable' options are controlled by other useflags. The bindist useflag in this case now does _nothing_ by itself. It just tells you what other option you must disable. I bet that if you manually disable faac because of bindist you'll know it did that and dont need to know this beforehand. (In reply to comment #7) > If describing the flag in 'use.local.desc' is impractical because the > meaning can change radically from ebuild to ebuild, then that tells me you > shouldn't be using that flag in the first place. Use a different flag, with > a name that indicates, to some extent, what is actually being done. This is completely killing the point of the useflag actually. If your crusade is against this then you should stop it right now. If I'm setting up a binary server, I want to setup one single useflag and make sure i'm ok with the laws, not study the license and meaning of every single useflag of every single package... (In reply to comment #7) > As indicated in my original report, the information on 'bindist' in > 'use.desc' is completely useless, since it could literally do _anything_ in > any particular package. (In freetype, for example, it used to enable or > disable the "TrueType bytecode interpreter". Now the 'auto-hinter' flag is > used instead.) Meaning people not reading the use.local.desc of the auto-hinter useflag, trusting the 'bindist' useflag and distributing binary packages are infringing the law? nice work, really :)
Ah, now we're getting somewhere. You are correct that I misunderstood. (I should point out that your snarky comments ["So is ranting...", "You probably didnt even try..."] didn't help enlighten me.) In the past, AFAIR, the nature of the 'bindist' flag has been confusing because regular users (not binary redistributors) needed to enable or disable it on some packages to control regular user-preference sort of options. Maybe the only instance of this was actually freetype's auto-hinter vs. byte code interpreter. I don't remember. But yes, if the 'bindist' flag is _only_ used to force/require _other_ USE flags to be enabled or disabled, that's fine. (I would still prefer a better default description of the flag. So, off to report another bug for that...) > > (In freetype, for example, it used to enable or > > disable the "TrueType bytecode interpreter". Now the 'auto-hinter' flag is > > used instead.) > > Meaning people not reading the use.local.desc of the auto-hinter useflag, > trusting the 'bindist' useflag and distributing binary packages are > infringing the law? nice work, really :) Are you implying that I may be responsible for people accidentally breaking the law? Wow. Now who's commenting "without understanding what has changed"? No, meaning that 'bindist' no longer controls the use of the byte code interpreter because it's no longer patented. The byte code'r is enabled by default and users who prefer the auto-hinter can use the option of that name, instead of using the 'bindist' flag. People now using 'bindist' just don't get ClearType-style subpixel rendering (which is patented). From the freetype-2.4.9-r1 ebuild: > if ! use bindist; then > # See http://freetype.org/patents.html > # ClearType is covered by several Microsoft patents in the US > enable_option FT_CONFIG_OPTION_SUBPIXEL_RENDERING > fi > > if use auto-hinter; then > disable_option TT_CONFIG_OPTION_BYTECODE_INTERPRETER > enable_option TT_CONFIG_OPTION_UNPATENTED_HINTING > fi ... > pkg_postinst() { > elog "The TrueType bytecode interpreter is no longer patented and thus no" > elog "longer controlled by the bindist USE flag. Enable the auto-hinter" > elog "USE flag if you want the old USE="bindist" hinting behavior." > } - - - > This is completely killing the point of the useflag actually. If your > crusade is against this then you should stop it right now. I never considered a "crusade" against the flag itself until I started talking to you. Nice work. ;-)
(In reply to comment #9) > Ah, now we're getting somewhere. You are correct that I misunderstood. (I > should point out that your snarky comments ["So is ranting...", "You > probably didnt even try..."] didn't help enlighten me.) read again comment #1 and comment #3 with that in mind then please > > > > Meaning people not reading the use.local.desc of the auto-hinter useflag, > > trusting the 'bindist' useflag and distributing binary packages are > > infringing the law? nice work, really :) > > Are you implying that I may be responsible for people accidentally breaking > the law? Wow. Now who's commenting "without understanding what has > changed"? (reordering the quote) > > > (In freetype, for example, it used to enable or > > > disable the "TrueType bytecode interpreter". Now the 'auto-hinter' flag is > > > used instead.) I read this as 'bindist was not descriptive enough so it changed to its own useflag', you didnt mention the following before: > No, meaning that 'bindist' no longer controls the use of the byte code > interpreter because it's no longer patented. The byte code'r is enabled by > default and users who prefer the auto-hinter can use the option of that > name, instead of using the 'bindist' flag. In which case the freetype example is irrelevant to this bug because the situation is different...
OK, this is absolutely the last comment I'm making on this bug. You continue to ignore the actual nature of the bug I'm reporting. I think you're intentionally being obtuse about this, so I'm done with you.
This is still a bug. All packages that use bindist should provide local descriptions of what is happening. This should not be made into the end-user's responsibility any more than finding the exact licence. Please re-open the bug and fix it.
