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?
I think changing the build based on lsb_release or DEB_VENDOR output in
their current form is going to mean more work for derivatives and
surprize breakages downstream (typically not for Debian and Ubuntu).
Instead, I think it would be nice if we could express some inheritance
concept so that you can have conditional behavior in rules based on
either "this distribution and its derivatives" or "only for this exact
distribution" and logical combinations such as "derivatives of Foo
except derivatives of Bar".
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
