| 1 |
On Wednesday 17 December 2003 09:10, Marius Mauch wrote: |
| 2 |
> On 12/17/03 Jason Stubbs wrote: |
| 3 |
> > Hmmm, I didn't get this email. |
| 4 |
> > |
| 5 |
> > On Tuesday 16 December 2003 21:59, Marius Mauch wrote: |
| 6 |
> > > One problem I see with the tree represenations (and a flag being |
| 7 |
> > > present in multiple leafs) is an ordering probem. E.g. we have |
| 8 |
> > > use.gui.gnome.esd (as esd is part of gnome) and use.sound.esd. Now a |
| 9 |
> > > user has "-use.gui.gnome +use.sound", is esd enabled then or not? |
| 10 |
> > |
| 11 |
> > Personally, I think that flags being present in multiple leafs of a |
| 12 |
> > tree would be a bad thing. It adds unneeded complexity on the dev side |
| 13 |
> > and confusion on the user side. With a well designed tree, it |
| 14 |
> > shouldn't occur anyway. To take your example, use.gui.gnome.esd |
| 15 |
> > shouldn't exist because esd is not a gui. |
| 16 |
> |
| 17 |
> Hmm, but AFAIK esd is considered a part of the Gnome desktop, same for |
| 18 |
> arts/KDE. So if I (as a user) disable gnome I'd expect that esd is |
| 19 |
> disabled too. Actually it's the same problem we have with categories, |
| 20 |
> things can fit in multiple branches. |
| 21 |
|
| 22 |
You're right. That could be confusing for the user to. It makes it more |
| 23 |
difficult to develop, but one possibility would be to have groupings (apart |
| 24 |
from the tree). For example: |
| 25 |
|
| 26 |
gui.gtk |
| 27 |
sound.esd |
| 28 |
@de.gnome = (gui.gtk sound.esd) |
| 29 |
|
| 30 |
Actually, this isn't much different to having a flag present in multiple |
| 31 |
leafs, except maybe easier to maintain. As for ordering, I would say that the |
| 32 |
last directive specified should be followed as is the case with the current |
| 33 |
implementation. It's not the most intuitive, but at least it's easily |
| 34 |
predictable. For example: |
| 35 |
|
| 36 |
"-de.gnome +sound.esd" = "-gui.gtk +sound.esd" |
| 37 |
"-gui.gtk -sound.esd +de.gnome" = "+gui.gtk +sound.esd" |
| 38 |
|
| 39 |
|
| 40 |
|
| 41 |
I've just thought of another possibility with regard to USE flag defaults. |
| 42 |
Presently, they're specified globally and are set depending on the arch, |
| 43 |
right? Do they actually differ for the archs at all? I tried diffing the |
| 44 |
use.defaults files but not much immediate results. |
| 45 |
|
| 46 |
Anyway, my proposal is that defaults are moved from a global setting to the |
| 47 |
ebuilds. Integrating with my other proposal, ebuilds would have something to |
| 48 |
the effect of PRODIVES, PREFERS, SUPPORTS with the following definitions: |
| 49 |
|
| 50 |
PROVIDES - intrinsic functionality to the package. If the use has specified |
| 51 |
the directive "-" for this flag then the package is masked. |
| 52 |
PREFERS - optional functionality that is usually required/expected. If this |
| 53 |
flag has a directive specified then it is followed. Otherwise, it is assumed |
| 54 |
to be "+". |
| 55 |
SUPPORTS - optional functionality that is usually not required/expected. If |
| 56 |
this flag has a directive specified then it followed. Otherwise, if a package |
| 57 |
is installed that provides this flag then it is assumed to be "+". In all |
| 58 |
other cases, it is assumed to be "-". |
| 59 |
|
| 60 |
What prompted this is packages that have a lot of options such as mplayer. |
| 61 |
mplayer has support for esd. If gnome PREFERS esd then, with the above rules, |
| 62 |
mplayer would be compiled with esd by default. Similarly, gcc could be |
| 63 |
compiled without java support by default where mozilla would be compiled with |
| 64 |
it. |
| 65 |
|
| 66 |
I wont bother giving many examples to back it up, but this would get around |
| 67 |
the need for users having to specify 10s to 100s of flags. The behaviour of |
| 68 |
SUPPORTS when no directive is specified should probably be optional. Other |
| 69 |
than that, what do you think? |
| 70 |
|
| 71 |
-- |
| 72 |
Regards, |
| 73 |
Jason Stubbs |
| 74 |
|
| 75 |
-- |
| 76 |
gentoo-portage-dev@g.o mailing list |
Archives