On Thu, 02 Jan 2014 22:33:20 +0100 Quentin Glidic <[email protected]> wrote: > Attached the grepped list of files. There are Perl modules, image > loading/manipulation tools, systemd/pm-utils, DHCP clients, Java > stuff, Ruby slots (Weechat). > A few are already being taking care of, through pending-removal > (modules-init-tools, farsight2).
Thanks. > > [...] > >> 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? > > It would be the build-time vs. runtime aspect of the := dependency > that would matter here. I would go with :libav and :ffmpeg > (inter-blocked) so changing slot would mean changing implementation, > while forcing a rebuild. So how about versioning of the virtuals? > >> 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. > > You mean: > DEFAULT_SRC_CONFIGURE_PARAMS=( > --disable-ffmpeg > ) > DEFAULT_SRC_CONFIGURE_OPTIONS=( > 'ffmpeg --enable-ffmpeg' > 'libav --enable-ffmpeg' > ) > ? Why not… No, I didn't. I thought we were discussing when at-least-one had to be enabled. I see your point. > >> 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? > > Say package A have ffmpeg and libav options, and package B ffmpeg > only. Having "*/* ffmpeg libav" will lead to the libav dependency of > A and the ffmpeg dependency of B. > Of course, that would be the best option to force people to submit > patches for their preferred ffmpeg-aware programs to support > libav. :-) Ah. > > I think I personally prefer manual. It seems a lot easier to grasp > > if you've never looked at the package before. > > It is easier to read a doc and fill one list than to fill two > variables in sync. Maybe. > > I'm not sure I see a point in bothering with a virtuals suboption. > > To keeps things clean, and you only need to write it once per place > (options.conf, MYOPTIONS) except in DEPENDENCIES, but here > virtual.exlib helps you a lot. Clean? Most of this is arguing the cost is minor. Not that there's a particular advantage. -- Bo Ørsted Andresen _______________________________________________ Exherbo-dev mailing list [email protected] http://lists.exherbo.org/mailman/listinfo/exherbo-dev
