| 1 |
On Fri, 3 Mar 2006 22:44:22 +0000, |
| 2 |
"Stuart Herbert" <stuart.herbert@×××××.com> wrote: |
| 3 |
|
| 4 |
> Unless a user looks inside the ebuild, they're not going to |
| 5 |
> understand why the USE flags they've selected has resulted in a |
| 6 |
> package that doesn't actually have those features. |
| 7 |
... |
| 8 |
> This is going to *create* more support, not reduce it. |
| 9 |
|
| 10 |
The problem here, from a user point of view, is the USE flag usage not |
| 11 |
matching its description (that's what makes "unexpected" the ebuild |
| 12 |
behavior). For instance, description says "foo - Enable libfoo", |
| 13 |
whereas actually the ebuild will only use libfoo if some other "bar" is |
| 14 |
unset. |
| 15 |
|
| 16 |
One point of view on this issues is that the ebuilds are wrong, because |
| 17 |
they are abusing the said USE flags, and they should rather die. Imho, |
| 18 |
it makes sense, but if such a strict policy was applied to every |
| 19 |
ebuilds which atm are abusing flags this way, it would become really |
| 20 |
hard to put anything in the make.conf USE variable without breaking |
| 21 |
"emerge -uD world". |
| 22 |
Just take the default flags from x86 profile for instance: both "motif" |
| 23 |
("Adds motif support") and "gtk" ("Adds support for x11-libs/gtk+") are |
| 24 |
enabled, whereas the logic in several packages supporting both is to |
| 25 |
build the GTK interface when "gtk" is on, and to build a Motif one |
| 26 |
otherwise, if "motif" is on. Do you think such ebuilds should rather |
| 27 |
die at compile time, asking the user to make an unconflicting choice? |
| 28 |
I don't. My package.use is already ~200 lines long for various other |
| 29 |
reasons, and i really don't want to double its size again just to |
| 30 |
make my "emerge -uD world" successfully terminating. |
| 31 |
|
| 32 |
Now, an alternative point of view is that what is wrong is rather the |
| 33 |
USE flag descriptions. That's exactly what the "package specific USE |
| 34 |
flag descriptions" proposal, which popups on this list from time to |
| 35 |
time, is about (sorry, no URL because GMane seems down, but i can post |
| 36 |
some later if you're interested). |
| 37 |
The idea (or at least my pov on this idea, but others had different |
| 38 |
views iirc) is that emerge could display some package-specific flags |
| 39 |
descriptions in such cases. Using the emerge patch from bug #84884, |
| 40 |
and with a "use.local.desc" entry for "app-editors/gvim:motif", the |
| 41 |
user would be warned about what the "motif" flag actualy does (or does |
| 42 |
not) on this package: |
| 43 |
|
| 44 |
--------------- |
| 45 |
% emerge -pv --use-desc-special gvim |
| 46 |
... |
| 47 |
[ebuild R ] app-editors/gvim-6.4 USE="-acl bash-completion cscope |
| 48 |
gnome gpm gtk motif nls -perl python ruby" 0kB |
| 49 |
... |
| 50 |
The following USE flags have package-specific descriptions: |
| 51 |
app-editors/gvim |
| 52 |
motif - Include support for the Motif GUI, but if "gtk" or "gnome" |
| 53 |
flags are turned on too, in which case they are prefered. |
| 54 |
--------------- |
| 55 |
|
| 56 |
This way, nothing unexpected for users, and no complain for devs. |
| 57 |
|
| 58 |
-- |
| 59 |
TGL. |
| 60 |
-- |
| 61 |
gentoo-dev@g.o mailing list |
Archives