On Mon, 30 Dec 2013 22:55:29 +0100 Quentin Glidic <[email protected]> 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 _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
