public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Dan Armak <danarmak@gentoo.org>
To: gentoo-dev@cvs.gentoo.org
Subject: [gentoo-dev] Suggestion: DONT_USE flags
Date: Wed Jul 18 05:29:02 2001	[thread overview]
Message-ID: <01071814294000.00590@localhost> (raw)

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



             reply	other threads:[~2001-07-18 11:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-18  5:29 Dan Armak [this message]
2001-07-18 11:13 ` [gentoo-dev] Suggestion: DONT_USE flags Daniel Robbins
2001-07-18 11:20   ` Dan Armak
2001-07-18 11:53     ` Daniel Robbins
2001-07-18 12:06       ` Dan Armak
  -- strict thread matches above, loose matches on Subject: below --
2001-07-18  7:34 Sean Mitchell
2001-07-18 10:54 ` Dan Armak
2001-07-18 11:39 Sean Mitchell
2001-07-18 11:41 Sean Mitchell
2001-07-18 12:14 Sean Mitchell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=01071814294000.00590@localhost \
    --to=danarmak@gentoo.org \
    --cc=gentoo-dev@cvs.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox