Bug 122158 – Wrong Use Flag "nodrm" in app-text/xpdf

• Product: Gentoo Linux
• Status: RESOLVED WORKSFORME

[Description Wolfgang Illmeyer 2006-02-08 11:14:07 UTC]

As far as I remember the mailing list, it is deprecated to have use-flags like "noXXX". Therefore, The use-flag "nodrm" should be renamed to "drm" and should remain disabled by default in any profile.
Thank you very much.

[Comment 1 Jakub Moc (RETIRED) 2006-02-08 11:28:17 UTC]

nodrm *disables* a feature *enabled* by default. USE=drm makes zero sense.

[Comment 2 Wolfgang Illmeyer 2006-02-08 12:21:29 UTC]

i meant not just renaming the use-flag, but of course also changing the semantics accordingly.

To qoute Michiel de Bruijne from gentoo-dev:

"
There are quite a few ebuilds in the tree that make use of a no<insert feature 
here> USE-flag. So basically by disabling the USE-flag you get more features. 
Pulling in extra dependencies by disabling the USE-flag is a possibility.


This has some nasty side effects, let me explain;

We are working on GLEP 19 (stable tree). Basically what we want to do is 
maintain a list of supported USE-flags and a list of supported packages. A 
script will create a stripped tree based on both lists. All the USE-flags in 
the stripped tree and not on the supported USE-flag list will end up in 
use.mask. This is to make sure that depgraph creation always complete 
successfully and we don't get any bugreports about missing ebuilds.

With no... USE-flags we need to remove these USE-flags manually from use.mask 
and ebuilds that are pulled in as a dependency as well. Also we need to find 
a way to enforce these USE-flags to be always on or else we might end up with 
reports about depgraph creation problems.

You can understand that this is not a nice task to do every time we change one 
or both of these lists. We also need to do it every time we create a new 
stripped tree from a different current tree.

This is just an example. Who knows what kind of nasty things we might 
encounter in the future when we continue doing this.
Using a single type of a switch to enable as well as disable options by 
turning the switch on is also something that usability experts don't like.


The only reason I can think of for using no... USE-flags is that the 
maintainer wants to provide an option for disabling a certain feature, but 
prefers that it's turned on by default and doesn't like to add an entry to 
make.defaults in the profile.


I'm willing to scan the tree for ebuilds with the no...USE-flags and create a 
bugreport and assign them to their corresponding herd/maintainer. After that 
the ebuild, use{.local.,.}desc and profile should be updated. If patches are 
requested I will make these as well. But it's self-evident that I will only 
do this if we come to a general agreement that the no...USE-flags shouldn't 
be in the tree and therefor added to the "ebuild submitting policy"

What do you think?
"

[Comment 3 Jakub Moc (RETIRED) 2006-02-08 12:36:54 UTC]

I think I don't have time to read the above. Upstream package *enables* DRM by default, we have USE=nodrm to disable it. USE=drm to *disable* drm just plain doesn't make any sense, as I said already once.

use.mask is completely irrelevant in this case, all this use flag does is patching of one file, no dependencies or whatever else.

Unless upstream changes the default to disabled, the use flag will remain as it is. Thanks.