[Exherbo-dev] [RFC] || ( ) dependencies and virtuals
Bo Ørsted Andresen
zlin at exherbo.org
Thu Jan 2 19:36:01 UTC 2014
On Mon, 30 Dec 2013 22:55:29 +0100
Quentin Glidic <sardemff7 at exherbo.org> wrote:
> There are a few other cases but I am not familiar enough with these
> so I will focus on the list above before “fixing” corner cases.
Have any sort of list of these? Might give us an idea about what these
> If we *cannot*, here are two and a half solutions:
> 1. a slot-based virtual. With a := slot dependency, that would force
> people to rebuild packages if they change from libav to ffmpeg
It's not clear to me how this would work? := takes the slot of the best
visible version. How would those versions be decided?
> 2. use [ffmpeg] and [libav] on each package, two variants here:
> a. make them mutually exclusive (but this is not
> DEFAULT_SRC_CONFIGURE_*-friendly, unless we add something to handle
> that choose-between -two-implementations case, which is quite common)
Don't see why that wouldn't be workable with
> b. make [libav] prefer libav over ffmpeg, while [ffmpeg] is always
> “use that feature” (which may confuse people for packages
> non-libav-aware that will lead to a blocker)
Could also go with a suboption.
> The autotools.exlib case can be solved in two ways:
> 1. a new annotation "|| ( ) [[ selection = first-unmasked ]]"
Sounds fine to me.
> 2. always use the best slot available (which would simplify a lot of
You mean only allow one slot in SUPPORTED_AUTO* ? It means you can't
mark a slot supported while it's still masked during early testing.
Similar issue if we ever start supporting some form of stable vs
testing, though I don't know that we ever will.
> Last but not least, the virtuals. Simple: || ( ) dependencies in
> virtuals need to die. The elegant solution came from Ciaran:
> option-driven virtuals. You will find attached to this email an
> example. The first part is such a virtual created by hand. The second
> part is the same virtual using virtual.exlib to fill MYOPTIONS and
> DEPENDENCIES automatically. The last part is the resulting "cave show
> -c". Which solution (manual or exlib) do you prefer, or do you have
> another idea?
I think I personally prefer manual. It seems a lot easier to grasp if
you've never looked at the package before.
I'm not sure I see a point in bothering with a virtuals suboption.
> Of course, I will happily update everything we have currently to the
> new decided style.
While it's nice that you'll work on this, I'd encourage everybody to
help once we've decided how to proceed.
Bo Ørsted Andresen
More information about the Exherbo-dev