[gentoo-dev] Suggestion: DONT_USE flags

[gentoo-dev] Suggestion: DONT_USE flags

[Dan Armak]

Hi all,

I want to raise the question of the correct usage of USE flags.

For example, I'm building an ebuild for a game which can optionally use 
vorbis and/or smpeg, which provide functionality for playing Vorbis or 
MP3-format music. Without these, the game can only play .wav files and CDA 
tracks. 

Now, there exists a USE vorbis flag. I can depend on this in deciding, in the 
ebuild, whether to include vorbis support or not.
However, if USE vorbis isn't set but Vorbis is already installed, should I 
use it?

A worse situation: there is no smpeg USE flag. I have 4 options:
1. Force usage of smpeg.
2. Use smpeg if it's already installed.
3. Never use smpeg.
4. Create a USE smpeg flag.

Option 4 I dismiss. If we create USE flags for every shared library and util 
which might possibly be used by another package, there will be a hundred 
falgs or more and a user won't be able to take time to understand the meaning 
of each and decide on setting it or not.
There seems no reason to do option 3. Option 2 might seem to be a good 
default, but what about option 1? Is there any good reason not to use smpeg, 
if it takes only 20 mins to d/l and install and adds important functionality? 
If there is, we should create a DONT_USE smpeg flag :-)

There's more to it than that, however. Suppose the user has no Internet 
cinnection, right now or at all. He may have the ource archives of the game, 
but not of smpeg. If we make smpeg a required dependency, he won't be able to 
install without modifying the ebuild.

This is why I think that instead of using cumbersome USE flags, we should 
very simply ask the user (interactively) what optional dependencies he wants. 
The USE flags would be used as default choices for a non-interactive 
installation process. I think this is much more simple and elegant than 
making the user's choices for him!

Comments welcome!


-- 

Dan Armak
Gentoo Linux Developer
Matan, Israel

RE: [gentoo-dev] Suggestion: DONT_USE flags

[Sean Mitchell]

Here's my 2 cents worth.... 

> Now, there exists a USE vorbis flag. I can depend on this in 
> deciding, in the 
> ebuild, whether to include vorbis support or not.
> However, if USE vorbis isn't set but Vorbis is already 
> installed, should I 
> use it?

To me, vorbis should only be used if the USE variable is set. I'd me annoyed
if I installed vorbis to test something out and ended up with a package that
decided to use it without a USE.
 
> A worse situation: there is no smpeg USE flag. I have 4 options:
> 1. Force usage of smpeg.
> 2. Use smpeg if it's already installed.
> 3. Never use smpeg.
> 4. Create a USE smpeg flag.
> 
> Option 4 I dismiss. If we create USE flags for every shared 
> library and util 
> which might possibly be used by another package, there will 
> be a hundred 
> falgs or more and a user won't be able to take time to 
> understand the meaning 
> of each and decide on setting it or not.

Agree.

> There seems no reason to do option 3. Option 2 might seem to 
> be a good 
> default, but what about option 1? Is there any good reason 
> not to use smpeg, 
> if it takes only 20 mins to d/l and install and adds 
> important functionality? 

This comes down to the ebuilder's decision. I am in favour of comments in
the .ebuild file so that intermediate users can fine tune things like this.


> If there is, we should create a DONT_USE smpeg flag :-)

I don't like that.

> This is why I think that instead of using cumbersome USE 
> flags, we should 
> very simply ask the user (interactively) what optional 
> dependencies he wants. 
> The USE flags would be used as default choices for a non-interactive 
> installation process. I think this is much more simple and 
> elegant than 
> making the user's choices for him!

As soon as you presented the problem this is what I thought the solution
should be. Of course, in order to be script-driven we should be able to
specify these on the command line.

This keeps the USE variable down to things that are system-wide choices
(ALSA, MMX/3DNOW, etc) but still allows fine tuning of the end product. The
only drawback that I see is that it will complicate the process of making
ebuilds a bit.

If emerge could support package specific USE variable (maybe WITH?) then it
could not only accomodate the scenario you present but even allow a really
eager ebuilder to create (for example) an ebuild for XFree86 that asks you
for your mouse, keyboard, etc and sets XF86Config appropriately.

Now perhaps Daniel, Achim, and everyone might not want something like this
for Gentoo Linux proper, but if I were making a Gentoo based distibution
targetted at a customer with multiple configurations (which I hope to one
day do) it would become very attractive.

At any rate I'd like to see something like...

lucaya /root > emerge --interactive sys-lib/STLport.4.0.ebuild

 Use SGI IOstreams? [Y/n]

...or the alternate form...

lucaya /root > emerge --with SGI_IO sys-lib/STLport.4.0.ebuild

...which could have the ebuild read something like...

src_compile()
{
   if [ "`with SGI_IO`" ]
   then
      CONFIGURE_OPTIONS="--enable-SGI_IOSTREAMS" 
   fi

   try ./configure --prefix ${D}/usr ${CONFIGURE_OPTIONS}
}


Keep in mind that this 2 cents Canadian, so depending on the current
exchange rate it's really only around 1.2 cents worth....

Cheers,

Sean

------------------------------------------------------------------------
 Sean Mitchell                                        Software Engineer
 smitchell@phoenix-interactive.com       Phoenix Interactive Design Inc
 tel. 519-679-2913 x237                        4th Floor, 137 Dundas St
 fax. 519 679 6773                          London, ON, Canada  N6A 1E9
                           ICQ# 104246806
------------------------------------------------------------------------ 

Re: [gentoo-dev] Suggestion: DONT_USE flags

[Dan Armak]

On Wednesday 18 July 2001 16:31, you wrote:
> Here's my 2 cents worth....
>
> > Now, there exists a USE vorbis flag. I can depend on this in
> > deciding, in the
> > ebuild, whether to include vorbis support or not.
> > However, if USE vorbis isn't set but Vorbis is already
> > installed, should I
> > use it?
>
> To me, vorbis should only be used if the USE variable is set. I'd me
> annoyed if I installed vorbis to test something out and ended up with a
> package that decided to use it without a USE.
>
> > A worse situation: there is no smpeg USE flag. I have 4 options:
> > 1. Force usage of smpeg.
> > 2. Use smpeg if it's already installed.
> > 3. Never use smpeg.
> > 4. Create a USE smpeg flag.
> >
> > Option 4 I dismiss. If we create USE flags for every shared
> > library and util
> > which might possibly be used by another package, there will
> > be a hundred
> > falgs or more and a user won't be able to take time to
> > understand the meaning
> > of each and decide on setting it or not.
>
> Agree.
>
> > There seems no reason to do option 3. Option 2 might seem to
> > be a good
> > default, but what about option 1? Is there any good reason
> > not to use smpeg,
> > if it takes only 20 mins to d/l and install and adds
> > important functionality?
>
> This comes down to the ebuilder's decision. I am in favour of comments in
> the .ebuild file so that intermediate users can fine tune things like this.
>
> > If there is, we should create a DONT_USE smpeg flag :-)
>
> I don't like that.
>
> > This is why I think that instead of using cumbersome USE
> > flags, we should
> > very simply ask the user (interactively) what optional
> > dependencies he wants.
> > The USE flags would be used as default choices for a non-interactive
> > installation process. I think this is much more simple and
> > elegant than
> > making the user's choices for him!
>
> As soon as you presented the problem this is what I thought the solution
> should be. Of course, in order to be script-driven we should be able to
> specify these on the command line.
>
> This keeps the USE variable down to things that are system-wide choices
> (ALSA, MMX/3DNOW, etc) but still allows fine tuning of the end product. The
> only drawback that I see is that it will complicate the process of making
> ebuilds a bit.
>
> If emerge could support package specific USE variable (maybe WITH?) then it
> could not only accomodate the scenario you present but even allow a really
> eager ebuilder to create (for example) an ebuild for XFree86 that asks you
> for your mouse, keyboard, etc and sets XF86Config appropriately.
>
> Now perhaps Daniel, Achim, and everyone might not want something like this
> for Gentoo Linux proper, but if I were making a Gentoo based distibution
> targetted at a customer with multiple configurations (which I hope to one
> day do) it would become very attractive.
>
> At any rate I'd like to see something like...
>
> lucaya /root > emerge --interactive sys-lib/STLport.4.0.ebuild
>
>  Use SGI IOstreams? [Y/n]
>
> ...or the alternate form...
>
> lucaya /root > emerge --with SGI_IO sys-lib/STLport.4.0.ebuild
>
> ...which could have the ebuild read something like...
>
> src_compile()
> {
>    if [ "`with SGI_IO`" ]
>    then
>       CONFIGURE_OPTIONS="--enable-SGI_IOSTREAMS"
>    fi
>
>    try ./configure --prefix ${D}/usr ${CONFIGURE_OPTIONS}
> }

I agree. I think interactive ebuilds are very powerful and important.

The ebuilds would ask questions - what libraries to link with etc., and 
possibly configuration options could be added. The USE flags would become the 
system-wide default answers.

In the meantime, if drobbins/achim/everyone else don't want to change emerge 
to suit (maybe not yet), we should at least decide on a standard 
question/ansewr format and perhaps add a simple handler function to emerge.
-- 

Dan Armak
Gentoo Linux Developer
Matan, Israel

Re: [gentoo-dev] Suggestion: DONT_USE flags

[Daniel Robbins]

On Wed, Jul 18, 2001 at 02:29:40PM +0300, Dan Armak wrote:

> A worse situation: there is no smpeg USE flag. I have 4 options:
> 1. Force usage of smpeg.
> 2. Use smpeg if it's already installed.
> 3. Never use smpeg.
> 4. Create a USE smpeg flag.
> 
> Option 4 I dismiss. If we create USE flags for every shared library and util 
> which might possibly be used by another package, there will be a hundred 
> falgs or more and a user won't be able to take time to understand the meaning 
> of each and decide on setting it or not.

The solution is to use option 4.  As soon as I have the dev team reorganized,
I'll be adding some much-needed USE upgrades to portage.  In addition to
allowing USE categories, the new USE behavior will allow certain options to be
"on by default".  This will allow the system profile to set "media(smpeg)" on
automatically, and it will even be enabled if the user doesn't have
"media(smpeg)" in his USE variable in make.conf.  If he wants to disable it,
he'll need to explicitly type "-media(smpeg)".  This will allow us to hide a
lot of complex USE variables from the end-user and keeping the difficult USE
work in the system profile.  This way, novice users are much less likely to
accidentally disable critical components by accidentally deleting a USE variable
from make.conf.

> There seems no reason to do option 3. Option 2 might seem to be a good 
> default, but what about option 1? Is there any good reason not to use smpeg, 
> if it takes only 20 mins to d/l and install and adds important functionality? 
> If there is, we should create a DONT_USE smpeg flag :-)

It is fine to force the use of a particular package as long as an overwhelmingly
large percentage of the people would want such functionality built-in.  But, if
it's simply an optional component that some people may not want, it should be 
configured via a USE variable.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Suggestion: DONT_USE flags

[Dan Armak]

On Wednesday 18 July 2001 20:12, you wrote:
> On Wed, Jul 18, 2001 at 02:29:40PM +0300, Dan Armak wrote:
> > A worse situation: there is no smpeg USE flag. I have 4 options:
> > 1. Force usage of smpeg.
> > 2. Use smpeg if it's already installed.
> > 3. Never use smpeg.
> > 4. Create a USE smpeg flag.
> >
> > Option 4 I dismiss. If we create USE flags for every shared library and
> > util which might possibly be used by another package, there will be a
> > hundred falgs or more and a user won't be able to take time to understand
> > the meaning of each and decide on setting it or not.
>
> The solution is to use option 4.  As soon as I have the dev team
> reorganized, I'll be adding some much-needed USE upgrades to portage.  In
> addition to allowing USE categories, the new USE behavior will allow
> certain options to be "on by default".  This will allow the system profile
> to set "media(smpeg)" on automatically, and it will even be enabled if the
> user doesn't have "media(smpeg)" in his USE variable in make.conf.  If he
> wants to disable it, he'll need to explicitly type "-media(smpeg)".  This
> will allow us to hide a lot of complex USE variables from the end-user and
> keeping the difficult USE work in the system profile.  This way, novice
> users are much less likely to accidentally disable critical components by
> accidentally deleting a USE variable from make.conf.
Well, that's certainly better than what there is now :-)

>
> > There seems no reason to do option 3. Option 2 might seem to be a good
> > default, but what about option 1? Is there any good reason not to use
> > smpeg, if it takes only 20 mins to d/l and install and adds important
> > functionality? If there is, we should create a DONT_USE smpeg flag :-)
>
> It is fine to force the use of a particular package as long as an
> overwhelmingly large percentage of the people would want such functionality
> built-in.  But, if it's simply an optional component that some people may
> not want, it should be configured via a USE variable.

I still think there should be optional user-interactive mode. It could print 
a suggestion based on the USE flags as the default choice, or accept a 
--silent flag and make all the default choices itself. For detais read the 
other messages in the thread (some of the replies are out-of-thread, the 
subject line changed).


-- 

Dan Armak
Gentoo Linux Developer
Matan, Israel

RE: [gentoo-dev] Suggestion: DONT_USE flags

[Sean Mitchell]

> -----Original Message-----
> From: Daniel Robbins [mailto:drobbins@gentoo.org]

> > Option 4 I dismiss. If we create USE flags for every shared 
> library and util 
> > which might possibly be used by another package, there will 
> be a hundred 
> > falgs or more and a user won't be able to take time to 
> understand the meaning 
> > of each and decide on setting it or not.
> 
> The solution is to use option 4.  As soon as I have the dev 
> team reorganized,
> I'll be adding some much-needed USE upgrades to portage.  In 

If everything is to be a USE variable then things will end up getting
unmanageable pretty quickly. Either that or you will have to make tradeoffs
between configurability and manageability.

For what it's worth, my opinion is that USE variables should apply across
the system as system defaults. As Dan pointed out, if you get too many of
them then the sheer volume of them will overwhelm even an intermediate user.

At the moment the only way to fine tune a package is to tweak the .ebuild.
When I created the .ebuild for STLport I decided that I would use the SGI
iostream libraries rather than wrappers around the system libraries. That's
fine for me, but it might create compatibility problems for your code. Now I
guess we could create a SGI_IO USE variable but the only package to which
this will be applicable is STLport. Surely an interactive mode or even just
command line specified variable would be a better solution. Your average
user would not be confronted with any change in user interface, nor would
(s)he need to figure a whole whack of obscure USE variables.

Another consideration is when there are multiple USE variables from which to
choose.

Take the case of Qt, GTK+, and Motif. Suppose you have a package that can
use any of them (no I don't know of any such packages). You would likely
have GTK, QT, and MOTIF all defined as USE variables, but which to use?
While an ebuilder can decide an order of preference, we're back to having to
like someone else's preferences. Furthermore, while I may prefer Qt for
package X, package Y is just so much better with GTK+.

Cheers,

Sean


------------------------------------------------------------------------
 Sean Mitchell                                        Software Engineer
 smitchell@phoenix-interactive.com       Phoenix Interactive Design Inc
 tel. 519-679-2913 x237                        4th Floor, 137 Dundas St
 fax. 519 679 6773                          London, ON, Canada  N6A 1E9
                           ICQ# 104246806
------------------------------------------------------------------------ 

RE: [gentoo-dev] Suggestion: DONT_USE flags

[Sean Mitchell]

> I agree. I think interactive ebuilds are very powerful and important.
> 
> The ebuilds would ask questions - what libraries to link with 
> etc., and 
> possibly configuration options could be added. The USE flags 
> would become the 
> system-wide default answers.
> 
> In the meantime, if drobbins/achim/everyone else don't want 
> to change emerge 
> to suit (maybe not yet), we should at least decide on a standard 
> question/ansewr format and perhaps add a simple handler 
> function to emerge.

I haven't taken a really good look at emerge yet, but from what I've seen
this could actually be implemented in the src_compile() function of the
ebuild itself. It would mean a bit of redundant functionality in the ebuilds
themselves, but I think it could accomplish the purpose.

Sean

------------------------------------------------------------------------
 Sean Mitchell                                        Software Engineer
 smitchell@phoenix-interactive.com       Phoenix Interactive Design Inc
 tel. 519-679-2913 x237                        4th Floor, 137 Dundas St
 fax. 519 679 6773                          London, ON, Canada  N6A 1E9
                           ICQ# 104246806
------------------------------------------------------------------------ 

Re: [gentoo-dev] Suggestion: DONT_USE flags

[Daniel Robbins]

On Wed, Jul 18, 2001 at 08:20:39PM +0300, Dan Armak wrote:

> > It is fine to force the use of a particular package as long as an
> > overwhelmingly large percentage of the people would want such functionality
> > built-in.  But, if it's simply an optional component that some people may
> > not want, it should be configured via a USE variable.
> 
> I still think there should be optional user-interactive mode. It could print 
> a suggestion based on the USE flags as the default choice, or accept a 
> --silent flag and make all the default choices itself. For detais read the 
> other messages in the thread (some of the replies are out-of-thread, the 
> subject line changed).

If people want an interactive mode, we can add one (I have no reason to oppose
it, as long as a non-interactive build is the default).  It could be really
handy. But we need the new USE system first.  In the meantime, I have no
problem with you discussing how you'd like an interactive build mode to work,
since we'll most likely add one eventually.

Best Regards,

-- 
Daniel Robbins					<drobbins@gentoo.org>
President/CEO					http://www.gentoo.org 
Gentoo Technologies, Inc.			

Re: [gentoo-dev] Suggestion: DONT_USE flags

[Dan Armak]

On Wednesday 18 July 2001 20:52, you wrote:
> On Wed, Jul 18, 2001 at 08:20:39PM +0300, Dan Armak wrote:
> > > It is fine to force the use of a particular package as long as an
> > > overwhelmingly large percentage of the people would want such
> > > functionality built-in.  But, if it's simply an optional component that
> > > some people may not want, it should be configured via a USE variable.
> >
> > I still think there should be optional user-interactive mode. It could
> > print a suggestion based on the USE flags as the default choice, or
> > accept a --silent flag and make all the default choices itself. For
> > detais read the other messages in the thread (some of the replies are
> > out-of-thread, the subject line changed).
>
> If people want an interactive mode, we can add one (I have no reason to
> oppose it, as long as a non-interactive build is the default).  It could be
> really handy. But we need the new USE system first.  In the meantime, I
> have no problem with you discussing how you'd like an interactive build
> mode to work, since we'll most likely add one eventually.
>
OK! This thread broke up into several threads due to different subject lines, 
and the subject isn't right any more anyway, so Ill post a new message with 
my suggestions based on this discussion.
-- 

Dan Armak
Gentoo Linux Developer
Matan, Israel

RE: [gentoo-dev] Suggestion: DONT_USE flags

[Sean Mitchell]

> If people want an interactive mode, we can add one (I have no 
> reason to oppose
> it, as long as a non-interactive build is the default).  It 
> could be really
> handy. But we need the new USE system first.  In the 
> meantime, I have no
> problem with you discussing how you'd like an interactive 
> build mode to work,
> since we'll most likely add one eventually.

I agree that non-interactive should always be the default. My feeling is
that a user who has specific needs should be able to fine tune things by
going into interactive mode. But by the same token, I think that you should
be able to accomplish everything on the command line that you can
interactively. 

I'd like to help with this, as I have some interest in it.

Sean

------------------------------------------------------------------------
 Sean Mitchell                                        Software Engineer
 smitchell@phoenix-interactive.com       Phoenix Interactive Design Inc
 tel. 519-679-2913 x237                        4th Floor, 137 Dundas St
 fax. 519 679 6773                          London, ON, Canada  N6A 1E9
                           ICQ# 104246806
------------------------------------------------------------------------