[Exherbo-dev] [RFC] || ( ) dependencies and virtuals

Quentin Glidic sardemff7 at exherbo.org
Fri Jan 3 23:00:04 UTC 2014


On 02/01/2014 22:39, Bo Ørsted Andresen wrote:
> On Thu, 02 Jan 2014 22:33:20 +0100
> Quentin Glidic <sardemff7 at exherbo.org> wrote:
>> 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?

What do you mean? Versions would be library-based. The dependency would 
look like "virtual/ffmpeg:=[>=${library_version}]".


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

Anyway that would work (with the --disable in _PARAMS). Sounds a little 
bit hacky but better to me than having src_configure define for just one 
option.


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

I have no really strong feeling against normal options, but I do get the 
feeling that separating this choice from normal options is a good 
forward-compatibility idea.

Side note, I would consider calling these new virtuals “choices” to 
please Ciaran. :-)


-- 

Quentin “Sardem FF7” Glidic



More information about the Exherbo-dev mailing list