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