[Exherbo-dev] || dependencies
ciaran.mccreesh at googlemail.com
Tue Jul 14 20:58:17 BST 2009
On Mon, 13 Jul 2009 19:55:31 +0100
Ciaran McCreesh <ciaran.mccreesh at googlemail.com> wrote:
> Do we need || dependencies? If so, why? What are they used for?
They appear to be used for:
1) I can build against either of these libraries.
2) I need or suggest one of these packages at runtime, and possibly at
build time (but not locked down) as well.
3) I need one of these versions of a thing.
4) I need foo built with either [bar] or [baz]
5) I need this thing that was once in foo, and has now been split out
6) I can use either foo or (foo-split-moo and foo-split-bar)
Are there any missing cases from this list?
As for killing || off...
1) should use options so that Paludis knows what it can uninstall.
3) should use version ranged deps or slot-a-or-slot-b deps (we don't
have the latter, but we could have easily)
4) needs support for [foo|bar] style option deps (which we could have
5) instead, make a foo-data-0 package that deps upon <foo-3, and a
foo-data-3 package that doesn't.
6) this one's a large source of why || is a massive pain in the ass. On
Gentoo, you got packages depping upon || ( qt ( qt-split-a
qt-split-b ) ), where qt and qt-split-* were mutually blocking. If you
only unmasked some of qt-split-*, paludis would have to select qt
instead, which would then block stuff already on the list, leading to
much ick. It would be much cleaner to make a split-qt option flag.
Which leaves 2).
I sort of want to say:
where virtual/opengl-implementation has:
MYOPTIONS="( xorg nvidia ) [[ number-selected = at-least-one ]]"
xorg? ( mesa-or-whatever )
nvidia? ( break-my-kernel )
Alternatively, we might be able to cover 2) with a new construct that
specifically only allows children in the form foo/bar or foo/bar[>=1].
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: not available
More information about the Exherbo-dev