[gentoo-portage-dev] The purpose of USE flags

[Jason Stubbs <jasonbstubbs@mailandnews.com>]

Hello all,

At the risk of sounding precocious, I think I'm going to open another can of 
worms. ;-)

I've been thinking on the idea of USE flags and am wondering what the 
developers' perspective is. They are defined in "Gentoo Guide to USE flags" 
as "keywords that define options used on a system-wide basis to configure 
applications during their respective compilation procedures". Is there any 
other, more formal, definition?

My reason for asking is that my feel, from the way developers and experience 
users talk about USE flags, that their usage has been mostly restricted to 
options provided by configure scripts. This is natural as (I assume) that's 
the way that USE flags evolved. However, I think that the the purpose of USE 
flags needs to be rethought, when implemented in portage-ng, to include how 
USE flags pertain to the system as a whole.

I was half thinking about it when I wrote the following except from my last 
mail:

On Tuesday 09 December 2003 07:06, Jason Stubbs wrote:
> USE flags need to be able to be grouped into 'super-USE' flags. For example: 
> "multimedia", "workstation", "server", etc.
> where "multimedia" = "video-codecs", "audio-codecs", "media-recording", etc.
> where "video-codecs" = "avi", "divx", "dvd", etc.

I'm going to expand on this idea a little, although I think it might not be 
well received due to the unexplained fear of USE flag explosion. My idea is 
that USE flags should be somewhat the equivalent of Microsoft Windows 
Installer's Product Feature selection tree, the main difference being that it 
applies to the whole operating system.

To explain further, I will again use an example possibility:
Multimedia
+ Recording
- Playback
  + Video
  - Audio
    + Audio Codecs
    - Audio Providers
      - OSS
      - ALSA
      - ARTS
      - ESD
      - <default>

From this small excerpt of a possible tree, you can image how big a full tree 
would be. The benefits of this style of tree are manyfold, but I'll just go 
over a few of the obvious (to me):

* Finer grain of control

Depending on what is actually implement of course, this model can offer much 
more control. If the above example is extended to include ALSA drivers, the 
model is shown to become a unified way to model all option behaviour of 
packages. Mozilla, for example, could be done in exactly the same way.

* Better categorization

With this USE flag model, if an ebuild-ng specifies what functionality it 
provides, both intrisically and optionally, packages become very easy to find 
for the end-user. It will also be easy to find other packages that do same 
things as a package that the user is familiar with.

That's all that I can think of at the moment. The only negative thing I can 
see is the explosion of USE flags. However, this is only a bad thing if they 
are uncategoriezed. Proper categorization should actually make them easier to 
understand and easier to maintain.

Well, that's enough said for now. All constructive criticism and any additions 
welcome.

-- 
Regards,
Jason Stubbs

--
gentoo-portage-dev@gentoo.org mailing list