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@×××××××××××××××××××.com       Phoenix Interactive Design Inc
 tel. [phone] x237                        4th Floor, 137 Dundas St
 fax. [phone]                          London, ON, Canada  N6A 1E9
                           ICQ# 104246806
------------------------------------------------------------------------