On Mon, 13 Jul 2009 19:55:31 +0100 Ciaran McCreesh <[email protected]> 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
into foo-data.
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
asily)
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:
DEPENDENCIES="run: virtual/opengl-implementation"
where virtual/opengl-implementation has:
MYOPTIONS="( xorg nvidia ) [[ number-selected = at-least-one ]]"
DEPENDENCIES="
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].
--
Ciaran McCreesh
signature.asc
Description: PGP signature
_______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
