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
next 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