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?
--
[email protected] mailing list
