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

[Jason Stubbs <jasonbstubbs@mailandnews.com>]

On Wednesday 17 December 2003 09:10, Marius Mauch wrote:
> On 12/17/03  Jason Stubbs wrote:
> > Hmmm, I didn't get this email.
> >
> > On Tuesday 16 December 2003 21:59, Marius Mauch wrote:
> > > One problem I see with the tree represenations (and a flag being
> > > present in multiple leafs) is an ordering probem. E.g. we have
> > > use.gui.gnome.esd (as esd is part of gnome) and use.sound.esd. Now a
> > > user has "-use.gui.gnome +use.sound", is esd enabled then or not?
> >
> > Personally, I think that flags being present in multiple leafs of a
> > tree would be a bad thing. It adds unneeded complexity on the dev side
> > and confusion on the user side. With a well designed tree, it
> > shouldn't occur anyway. To take your example, use.gui.gnome.esd
> > shouldn't exist because esd is not a gui.
>
> Hmm, but AFAIK esd is considered a part of the Gnome desktop, same for
> arts/KDE. So if I (as a user) disable gnome I'd expect that esd is
> disabled too. Actually it's the same problem we have with categories,
> things can fit in multiple branches.

You're right. That could be confusing for the user to. It makes it more 
difficult to develop, but one possibility would be to have groupings (apart 
from the tree). For example:

gui.gtk
sound.esd
@de.gnome = (gui.gtk sound.esd)

Actually, this isn't much different to having a flag present in multiple 
leafs, except maybe easier to maintain. As for ordering, I would say that the 
last directive specified should be followed as is the case with the current 
implementation. It's not the most intuitive, but at least it's easily 
predictable. For example:

"-de.gnome +sound.esd" = "-gui.gtk +sound.esd"
"-gui.gtk -sound.esd +de.gnome" = "+gui.gtk +sound.esd"



I've just thought of another possibility with regard to USE flag defaults. 
Presently, they're specified globally and are set depending on the arch, 
right? Do they actually differ for the archs at all? I tried diffing the 
use.defaults files but not much immediate results.

Anyway, my proposal is that defaults are moved from a global setting to the 
ebuilds. Integrating with my other proposal, ebuilds would have something to 
the effect of PRODIVES, PREFERS, SUPPORTS with the following definitions:

PROVIDES - intrinsic functionality to the package. If the use has specified 
the directive "-" for this flag then the package is masked.
PREFERS - optional functionality that is usually required/expected. If this 
flag has a directive specified then it is followed. Otherwise, it is assumed 
to be "+".
SUPPORTS - optional functionality that is usually not required/expected. If 
this flag has a directive specified then it followed. Otherwise, if a package 
is installed that provides this flag then it is assumed to be "+". In all 
other cases, it is assumed to be "-".

What prompted this is packages that have a lot of options such as mplayer. 
mplayer has support for esd. If gnome PREFERS esd then, with the above rules, 
mplayer would be compiled with esd by default. Similarly, gcc could be 
compiled without java support by default where mozilla would be compiled with 
it.

I wont bother giving many examples to back it up, but this would get around 
the need for users having to specify 10s to 100s of flags. The behaviour of 
SUPPORTS when no directive is specified should probably be optional. Other 
than that, what do you think?

--
Regards,
Jason Stubbs

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