[Exherbo-dev] [RFC] || ( ) dependencies and virtuals
Bo Ørsted Andresen
zlin at exherbo.org
Thu Jan 2 21:39:56 UTC 2014
On Thu, 02 Jan 2014 22:33:20 +0100
Quentin Glidic <sardemff7 at exherbo.org> 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).
> > [...]
> >> 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:
> '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. :-)
> > 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.
> > 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
Bo Ørsted Andresen
More information about the Exherbo-dev