[gentoo-dev] Proposal regarding use flags

[Troels Vognsen]

Hi !

At some point earlier today, the gentoo-hardened use flag discussion
evolved into a debate of the use flag system. The arch topic was the
amount of use flags, and how Gentoo could maintain the freedom
of choice while providing plenty of options.

This is a proposal on how (I think) the use flag situation (among a
few other things) could be improved. It's heavily inspired by the
suggestions made in the debate mentioned above.

 - - - - - - - - -

Profiles gets split up in two:
--arch-profiles: flags that affect the compilation/configuration of the entire system or *vital* components (like hardened and arch settings)
--purpose-profiles: flags that define the settings/dependecies suiting the target purpose (role)

This way I would rarely have to disable flags, because I largely chose
the base ones in the first place.

Global use flags are put into groups, grouped like the kernel.
Local use flags are put into groups, grouped by package.
That means we'll have 2 arch-groups, one for local-flag groups
and one for global-flag groups. Since we can the devide these
arch-groups into subgroups, we'll end up with something that
is organised like the make menuconfig for kernel 2.6. Lots of
options (mainly due to the local flags), but nicely organised.

Each use flag (wheter local or global) has 3 options:
0: disable
1: enable-no-dep (enable if it can be done, without installer further packages)
2: enable-with-dep (enable, even if it means installing additional packages)

This ensures that the use flags ain't controlling/expanding
the base of installed packages unless we want it to. This also
emphasises the purpose of the use flags: to tune packages and
manage features. 

Then installing kde won't look like:
- set the kde use flags
- (if accidently) emerge mc (or whatever package that ultimately depends)
I've seen a lot of users doing this, and I belive it's quite wrong.
As it is now, you can't seperate adding support for, and actually
installing the application.

Metapackages can enable (not disable) use flags. A seperate config
file is made for the flags enabled by each metapackage
(organised in a 'flags enabled by foo-package' way). We keep this
out of make.conf sice we wanna emphasise that the user ain't
supposed to modify it under normal circumbstances.

This will allow you to install major software packages, without
going through the use flag list every time.

The package groups mentioned above can be used as flags
themselves, by enclosing their name in @ in for instance make.conf.
It's possible to enable/disable groups and at the same time
enable/disable specific childs of that group.

The resulting value of the use flags are calculated as follows:
1. Default USE setting declared in /etc/make.profile/make.defaults
2. Inherited USE setting if a package from /etc/make.profile/use.defaults is installed
3. Metapackage-defined USE setting /etc/make.meta (or whatever we name the file)
4. User-defined USE setting in /etc/make.conf
5. User-defined USE setting as environment variable

The list of groups and global/local flags is resolved seperately at each
level, then the resulting list of global/local flags is merged with the one
inherited from the previous level (if any). As usual, a given levels
list takes presedence over the inherited one.

I know the group thing could be a little complicated, but the general
rule is: if the child of a group (be it a local/global flag or another
group) is specificly mentioned on the list of flags and groups, that
takes presedence over inheritance from the parent-group.

As I'm kinda new to Gentoo development, some terms might be
misunderstood. Likewise this is by no means meant to be a GLEP.
At most it's inspiration for a later one. 

I could possibly do an experimental bash/sed implimentation of the
idea to test it.

- Troels Vognsen :-)


--
gentoo-dev@g.o mailing list