[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEB_VENDOR and forks



Loïc Minier wrote:
> On Wed, Mar 18, 2009, Raphael Hertzog wrote:
>> I also included DEB_VENDOR in the set of variables. This variable is not
>> used currently (as I just introduced it with dpkg 1.15.0) but I expect it
>> to become more used in the future for things like this:
>> - enable additional patch/features depending on the vendor (while still
>>   sharing a common source package for better cooperation)
>> - special purpose derivative could change the behaviour of helpers like
>>   debhelper/CDBS based on this value (for example to strip doc for
>>   Emdebian, to extract debug infos in .ddeb, ...)
> 
>  While I appreciate the effort of providing DEB_VENDOR, I'd like to
>  raise a design issue with this approach which we'd best fix now.
> 
>  If you implement conditional behavior in your rules, typically based on
>  lsb_release -is output:
>  if vendor is Ubuntu:
>     foo
>  elif vendor is Debian:
>     bar
>  you face a problem when you meet:
>  else:
> 
>  What behavior should one use here?

There is a good use case for this that doesn't require a conditional, which is
passing --with-package-name=$(DEB_VENDOR) to configure for packages that have
this option (e.g. the GStreamer stack, that right now checks lsb_release -si output.

It doesn't solve your concerns but perhaps you could do some common action or
apply the Debian logic for anything else (which would be the same as not looking
at DEB_VENDOR at all).

Cheers,
Emilio

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: