[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
are.

[...]
> 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
DEFAULT_SRC_CONFIGURE_OPTIONS.

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

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
> things)

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 mailing list