Mailing List Archive

Firstly...

From http://devmanual.gentoo.org/general-concepts/use-flags/index.html

"Local and Global USE Flags

USE flags are categorised as either local or global. A global USE flag
must satisfy several criteria:

* It is used by many different packages.
* It has a general non-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.

Before introducing a new global USE flag, it must be discussed on the
gentoo-dev mailing list."


Steen Eugen Poulsen wrote:
> 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? As for the duplicate local USE flags, They are most
probably redundant.

>
> Lets take one of the big ones python. This use flag enables optional
> python support in many packages, I don't see my system ever using the
> python support in most of these. Seems like it really should be a local
> pr. packet flag for most, a pythonapi flag perhaps.

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.

>
> There is also a few cases where package X requires package Y to be
> compiled with an USE flag, but no testing is being done in the ebuild
> for it and the compilation fails. Example gnome-system-tools requires
> libxml2 to be compiled with python support.

If that is the case, then I would suggest you search bugzilla and then
file a bug.

>
> Then there is flags like alsa, it's marked as a global flag and then
> virtualbox also has it marked as a local flag. I personally think
> virtualbox is somewhat right in saying it's a local flag, but perhaps it
> would be better if the flag didn't have a double meaning.

See above. I can only assume that virtualbox doesn't need to have a
local alsa use flag.

>
> 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.
>
--
gentoo-dev@gentoo.org mailing list

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.

Ok, so I think I understand where you are coming from...

Firstly, USE flags are not meant to have a specific purpose. Enabling
python support is non-specific as it doesn't describe how it is enabled
or what python support actually is.

Lets compare 2 packages to demonstrate...

subversion has a python use flag, this flag will install a subversion
api for python. so within python you an interact with subversion.

as another example.

vim also has a python use flag. this flag enables the ability to
execute python commands from within vim.

_But_ it is important to note that nowhere does the python use flag
attempt to distinguish between the 2 types of support. This is where I
believe you are getting stuck.

The reason for having non-specific use flags is otherwise we would have
hundreds of duplicate local use flags whose descriptions differ only
slightly. We are not attempting to document all the functionality of
each package. It is up to you to discover what packages you want to
have python support.

>
> 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.
>

well I would only agree with that if you correlate the global status of
a USE flag to the number of packages that use it and you are wanting to
only enable the bare minimum use flags for the pacakges that you require.

But anyway, in summary

If you want to find out what a packages USE flag does, it is better to
read the upstream documentation.
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Steen Eugen Poulsen wrote:
> 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.

Right, the only indication is if you want the functionality of the flag
globally or per 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.

That's right. Global/local use flag descriptions have no relation to
global/local setting via make.conf/package.use. As a non-dev you might
just ignore the first classification.

>>> 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.

Well then don't enable those flags globally (that they are "global"
doesn't mean you have to), enable them only for packages which have
depending packages requiring them. Which you currently find out only by
errors (graceful die messages, except bugs like the one you mentioned :)
until there are finally use deps.

> 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.

Right, as mentioned above, there is no relation, although the
"global/local" notion may suggest it. One might even ask why we have
separate use.desc and use.local.desc then. Good question :) IMHO it's
mostly administrative thing so people don't add many new global flags
without consultation, but still can quickly add local flags just for
their package.

- --
Vlastimil Babka (Caster)
Gentoo/Java
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG42AktbrAj05h3oQRAkfjAJ4zdWFWzLAswbDTq/hvszouoI1gYgCfV/j4
w0aFRUzi5RbOJMAs9M7O3no=
=7Y8j
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list