| 1 |
Firstly... |
| 2 |
|
| 3 |
>From http://devmanual.gentoo.org/general-concepts/use-flags/index.html |
| 4 |
|
| 5 |
"Local and Global USE Flags |
| 6 |
|
| 7 |
USE flags are categorised as either local or global. A global USE flag |
| 8 |
must satisfy several criteria: |
| 9 |
|
| 10 |
* It is used by many different packages. |
| 11 |
* It has a general non-specific purpose. |
| 12 |
|
| 13 |
The second point is important. If the effect of the thing USE flag upon |
| 14 |
pkg-one is substantially different from the effect it has upon pkg-two, |
| 15 |
then thing is not a suitable candidate for being made a global flag. In |
| 16 |
particular, note that if client and server USE flags are ever |
| 17 |
introduced, they can not be global USE flags for this reason. |
| 18 |
|
| 19 |
Before introducing a new global USE flag, it must be discussed on the |
| 20 |
gentoo-dev mailing list." |
| 21 |
|
| 22 |
|
| 23 |
Steen Eugen Poulsen wrote: |
| 24 |
> I'm trying to write a Replicator for /etc/portage and that leads me to |
| 25 |
> work with USE flags, trying to design the replication of them among |
| 26 |
> similar systems, but I can't find the golden set of rules for how best |
| 27 |
> to apply USE flags. |
| 28 |
> |
| 29 |
> There seem to be a global/local USE flag system, but many so called |
| 30 |
> global flags has duplicated description marking them as local flags, or |
| 31 |
> they enable unneeded optional support. |
| 32 |
|
| 33 |
Unneeded by whom? As for the duplicate local USE flags, They are most |
| 34 |
probably redundant. |
| 35 |
|
| 36 |
> |
| 37 |
> Lets take one of the big ones python. This use flag enables optional |
| 38 |
> python support in many packages, I don't see my system ever using the |
| 39 |
> python support in most of these. Seems like it really should be a local |
| 40 |
> pr. packet flag for most, a pythonapi flag perhaps. |
| 41 |
|
| 42 |
See above. Also note that you are not enabling support for pythonapi, |
| 43 |
you are enabling support for python. Would you enable support for |
| 44 |
linuxheaders when you are without a linux kernel. |
| 45 |
|
| 46 |
> |
| 47 |
> There is also a few cases where package X requires package Y to be |
| 48 |
> compiled with an USE flag, but no testing is being done in the ebuild |
| 49 |
> for it and the compilation fails. Example gnome-system-tools requires |
| 50 |
> libxml2 to be compiled with python support. |
| 51 |
|
| 52 |
If that is the case, then I would suggest you search bugzilla and then |
| 53 |
file a bug. |
| 54 |
|
| 55 |
> |
| 56 |
> Then there is flags like alsa, it's marked as a global flag and then |
| 57 |
> virtualbox also has it marked as a local flag. I personally think |
| 58 |
> virtualbox is somewhat right in saying it's a local flag, but perhaps it |
| 59 |
> would be better if the flag didn't have a double meaning. |
| 60 |
|
| 61 |
See above. I can only assume that virtualbox doesn't need to have a |
| 62 |
local alsa use flag. |
| 63 |
|
| 64 |
> |
| 65 |
> As I see it, Gentoo's USE flag system is one of it's greatest strength, |
| 66 |
> but at the moment seems like there is missing some overall design for |
| 67 |
> how to implement USE flags, making it a lot harder to use USE flags, as |
| 68 |
> there is no clear definition of global or local flags. |
| 69 |
> |
| 70 |
-- |
| 71 |
gentoo-dev@g.o mailing list |
Archives