On Fri, 3 Mar 2006 22:44:22 +0000,
"Stuart Herbert" <[EMAIL PROTECTED]> wrote:

> Unless a user looks inside the ebuild, they're not going to
> understand why the USE flags they've selected has resulted in a
> package that doesn't actually have those features.
...
> This is going to *create* more support, not reduce it.

The problem here, from a user point of view, is the USE flag usage not
matching its description (that's what makes "unexpected" the ebuild
behavior).  For instance, description says "foo - Enable libfoo",
whereas actually the ebuild will only use libfoo if some other "bar" is
unset.

One point of view on this issues is that the ebuilds are wrong, because
they are abusing the said USE flags, and they should rather die.  Imho,
it makes sense, but if such a strict policy was applied to every
ebuilds which atm are abusing flags this way, it would become really
hard to put anything in the make.conf USE variable without breaking
"emerge -uD world".
Just take the default flags from x86 profile for instance: both "motif"
("Adds motif support") and "gtk" ("Adds support for x11-libs/gtk+") are
enabled, whereas the logic in several packages supporting both is to 
build the GTK interface when "gtk" is on, and to build a Motif one 
otherwise, if "motif" is on.  Do you think such ebuilds should rather 
die at compile time, asking the user to make an unconflicting choice?
I don't. My package.use is already ~200 lines long for various other 
reasons, and i really don't want to double its size again just to 
make my "emerge -uD world" successfully terminating.

Now, an alternative point of view is that what is wrong is rather the
USE flag descriptions.  That's exactly what the "package specific USE
flag descriptions" proposal, which popups on this list from time to 
time, is about (sorry, no URL because GMane seems down, but i can post 
some later if you're interested).
The idea (or at least my pov on this idea, but others had different 
views iirc) is that emerge could display some package-specific flags 
descriptions in such cases.  Using the emerge patch from bug #84884, 
and with a "use.local.desc" entry for "app-editors/gvim:motif", the 
user would be warned about what the "motif" flag actualy does (or does
not) on this package:

---------------
% emerge -pv --use-desc-special gvim
...
[ebuild   R   ] app-editors/gvim-6.4  USE="-acl bash-completion cscope
gnome gpm gtk motif nls -perl python ruby" 0kB
...
The following USE flags have package-specific descriptions:
app-editors/gvim
    motif - Include support for the Motif GUI, but if "gtk" or "gnome" 
flags are turned on too, in which case they are prefered.
---------------

This way, nothing unexpected for users, and no complain for devs.

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

Reply via email to