Alistair Bush skrev:
* It is used by many different packages.
yes, this is the rubber rule. It pretty much allows any use flag to be promoted to global when it has XX packages with it, the confusion comes because the number of package using a flag is no indication whatever you should set the flag globally or pr. package.
Seem to me that the word global is used in the portage tree to mean one thing and then when we edit make.conf and /etc/portage we get another global/local meaning.
* It has a general non-specific purpose.
Shouldn't that be "It has a general specific purpose".
The second point is important. If the effect of the thing USE flag upon pkg-one is substantially different from the effect it has upon pkg-two, then thing is not a suitable candidate for being made a global flag. In particular, note that if client and server USE flags are ever introduced, they can not be global USE flags for this reason.
Again you seem to talk about specific purpose, but the quoted text say non-specific, excuse me for being confused.
I'm trying to write a Replicator for /etc/portage and that leads me to work with USE flags, trying to design the replication of them among similar systems, but I can't find the golden set of rules for how best to apply USE flags. There seem to be a global/local USE flag system, but many so called global flags has duplicated description marking them as local flags, or they enable unneeded optional support.Unneeded by whom?
The package in order for it to work. You don't need Java, Python, Perl, Lua, whatever scripting support in most packages. For most of the ones I've seen, I have to go write a Java/Python/Perl/Lua program, before I actually need it.
> As for the duplicate local USE flags, They are most
probably redundant.
See above. Also note that you are not enabling support for pythonapi, you are enabling support for python. Would you enable support for linuxheaders when you are without a linux kernel.
I don't understand what support for python is.
If that is the case, then I would suggest you search bugzilla and then file a bug.
Off course, but thats hardly the point of mentioning here, it was for bringing general attention to a ebuild mistake, that happens again and again.
See above. I can only assume that virtualbox doesn't need to have a local alsa use flag.
alsa: Adds support for media-labs/alsa-lib (Advanced Linux Sound Architecture)
Local Flag: Enable support for ALSA instead of OSS (app-emulation/virtualbox)
In box's case it's an "alsa not oss" flag, the global flag tend to be "also alsa", though I wont put my head on the block claiming it's always that meaning it has.
As I see it, Gentoo's USE flag system is one of it's greatest strength, but at the moment seems like there is missing some overall design for how to implement USE flags, making it a lot harder to use USE flags, as there is no clear definition of global or local flags.
The words is given different meaning depending on whatever I'm looking at the portage tree or working on configuring emerge. The portage trees global flag, is no indication whatever I should put the flag in USE="" in make.conf, in many cases a portage tree global flag is more an indication that I should use it locally pr. package.
smime.p7s
Description: S/MIME Cryptographic Signature
