Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Mounir Lamouri <volkmar@g.o>
Subject: [RFC] USE flags requirements (EAPI-4 ?)
Date: Sun, 30 Aug 2009 19:06:02 +0200
Hi,

While writing and using some ebuilds, I had to deal with (pseudo) USE
flags requirements. For example, if you install mplayer with
USE="encode" the result will depend on other USE flags: if you have
USE="encode mp3", it will install lame for example. I know a few ebuilds
behave like that in the tree. We can also see some ebuilds that will
force an option if you set another one: if you set USE="-foo +bar" and
bar needs foo, it will silently set --enable-foo. Finally, they are some
ebuilds like >=ekiga-3 that will just fail if you have two USE flags
"conflicting": kontact needs kde so USE="kde -kontact" and USE="kde
kontact" are okay but USE="-kde kontact" will fail.

In my opinion, we can't keep auto-enabling some options because the user
has enabled another option without telling him and without telling the
package manager. For example, I'm a lambda user, I've set USE=kontact
but I don't know it's related to KDE, I don't have a KDE desktop and I
don't want one. With the regular behavior in the tree, kde will be
enabled silently and the user will don't have a clue about it like the
package manager. This last one is even worst because if we imagine a
library ebuild with this behavior used by other ebuilds in the tree,
EAPI-2 use dependencies will break. (foo ebuild depends on ekiga[kde],
user will have to rebuild ekiga if it has been built with USE="-kde
kontact" even if ekiga has been built with kde support or foo ebuild
depends on mplayer[mp3] should be mplayer[encode,mp3].

However, dying is probably not the best solution too.
So I think we should add a new feature in PMS already used in Exherbo
EAPI, USE flags requirements [1]. That means an ebuild should be able to
say a USE flag is available only if some other ones are in a specific state.
Let's take the mplayer example, if we have a line like this:
USE_REQUIREMENTS="encode? ( mp2 mp3 faac x264 xvid )", PM should be able
to show the user USE="mp3" will be ignored because he didn't set
USE="encode" and the PM will disable this USE flag by himself.
The same way, for ekiga:
USE_REQUIREMENTS="kde? ( kontact )", PM should be able to show the user
if he set USE="kontact", kde USE flag is enabled and the PM will enable
this USE flag by himself.

I think this new feature should help everyones life. We can also imagine
great features like a minimal USE-flag that will be something like:
USE_REQUIREMENTS="minimal? ( foo bar )" to set a list of USE flags to
disable if minimal USE flag is enabled. Combined to EAPI-1 auto-enabled
USE flags, it could help disabling all auto-enabled USE flags for some
uses... That's just an idea.

I'm not writing a GLEP draft so don't try to found an issue in the
syntax used, it's only to know if this kind of feature will be
appreciated by other users/devs than me and if it could be added to
EAPI-4 and worth to work on it.
I can write the GLEP and implement the feature in portage.

[1] http://www.exherbo.org/docs/exheres-for-smarties.html#myoptions

Thanks,
Mounir


Replies:
Re: [RFC] USE flags requirements (EAPI-4 ?)
-- Ciaran McCreesh
Re: [RFC] USE flags requirements (EAPI-4 ?)
-- Thomas Anderson
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
About udev-145: new features / extras and kernel requirements
Next by thread:
Re: [RFC] USE flags requirements (EAPI-4 ?)
Previous by date:
Re: [gentoo-dev-announce] Deprecation of Python 2.4
Next by date:
Re: [gentoo-dev-announce] Deprecation of Python 2.4


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.