FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 03-18-2009, 09:49 AM
Loc Minier
 
Default DEB_VENDOR and forks

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

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-18-2009, 11:02 AM
Emilio Pozuelo Monfort
 
Default DEB_VENDOR and forks

Loc 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
 
Old 03-18-2009, 11:56 AM
Loc Minier
 
Default DEB_VENDOR and forks

On Wed, Mar 18, 2009, Emilio Pozuelo Monfort wrote:
> 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.

Good point; that's similar to when the "exactly this vendor" check
makes sense

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

Applying the Debian logic is not good enough for e.g. derivatives of
Ubuntu as they want to fork the Ubuntu behavior and patches etc.

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-18-2009, 12:49 PM
Raphael Hertzog
 
Default DEB_VENDOR and forks

On Wed, 18 Mar 2009, Loïc Minier wrote:
> 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?

Debian should always be the "else" because it's the default case. It
ensures that the lack of DEB_VENDOR results in correct package and
also that any unknown derivatives get the Debian behaviour.

Of course an Ubuntu derivative could be surprised if they get
a Debian-variant of a package instead of an Ubuntu-variant… this explains
your other remark:

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

I see how we can solve it (add new fields in /etc/dpkg/origins/* to
describe parent relationship, and create a new tool to query those
meta-information) but I wonder what impact you expect it would have
on the decision of exporting DEB_VENDOR in the build environment.

Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
so that no external tool is required ?

ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
# Ubuntu or derivative
endif

Cheers,
--
Raphaël Hertzog

Contribuez * Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-18-2009, 12:57 PM
Loïc Minier
 
Default DEB_VENDOR and forks

On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> Of course an Ubuntu derivative could be surprised if they get
> a Debian-variant of a package instead of an Ubuntu-variant…

Yes, that's exactly the issue I'm raising

> I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> describe parent relationship, and create a new tool to query those
> meta-information) but I wonder what impact you expect it would have
> on the decision of exporting DEB_VENDOR in the build environment.

Well I just want this issue to be considered near the initial
introduction of DEB_VENDOR.

> Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
> so that no external tool is required ?
>
> ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
> # Ubuntu or derivative
> endif

That would be a possible implementation which I wouldn't mind using;
albeit the name of the field isn't too obvious but I don't have any
good idea. I think I'd be fine with either an external tool or
environment vars, but in any case the handling of specific vendor and
inherited vendors should be similar IMO.


Thanks!

--
Loïc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-18-2009, 01:00 PM
Loc Minier
 
Default DEB_VENDOR and forks

On Wed, Mar 18, 2009, Raphael Hertzog wrote:
> > if vendor is Ubuntu:
> > foo
> > elif vendor is Debian:
> > bar
> > you face a problem when you meet:
> > else:
> >
> > What behavior should one use here?
>
> Debian should always be the "else" because it's the default case. It
> ensures that the lack of DEB_VENDOR results in correct package and
> also that any unknown derivatives get the Debian behaviour.

[ There are two difference things here: I agree that if no vendor is
set, Debian should be assumed but I don't think the choice of Debian's
behavior for unknown vendors is the right one, I think I'd personally
prefer erroring out to raise the issue, but that's only if there's a
sane way to handle that properly, which could be your DEB_VENDORS
proposal. ]

--
Loc Minier


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-18-2009, 08:33 PM
Matthias Klose
 
Default DEB_VENDOR and forks

Raphael Hertzog schrieb:
> On Wed, 18 Mar 2009, Loïc Minier wrote:
>> 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?
>
> Debian should always be the "else" because it's the default case. It
> ensures that the lack of DEB_VENDOR results in correct package and
> also that any unknown derivatives get the Debian behaviour.
>
> Of course an Ubuntu derivative could be surprised if they get
> a Debian-variant of a package instead of an Ubuntu-variant… this explains
> your other remark:
>
>> 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".
>
> I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> describe parent relationship, and create a new tool to query those
> meta-information) but I wonder what impact you expect it would have
> on the decision of exporting DEB_VENDOR in the build environment.
>
> Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
> so that no external tool is required ?
>
> ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
> # Ubuntu or derivative
> endif

what about a command is_derivative <DEB_VENDOR> which could be used instead?
This wouldn't hard-code any specific vendor names.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-18-2009, 08:59 PM
Raphael Hertzog
 
Default DEB_VENDOR and forks

On Wed, 18 Mar 2009, Matthias Klose wrote:
> > I see how we can solve it (add new fields in /etc/dpkg/origins/* to
> > describe parent relationship, and create a new tool to query those
> > meta-information) but I wonder what impact you expect it would have
> > on the decision of exporting DEB_VENDOR in the build environment.
> >
> > Would you like a DEB_VENDORS="Gobuntu Ubuntu Debian" or similar
> > so that no external tool is required ?
> >
> > ifneq (,$(filter Ubuntu,$(DEB_VENDORS)))
> > # Ubuntu or derivative
> > endif
>
> what about a command is_derivative <DEB_VENDOR> which could be used instead?
> This wouldn't hard-code any specific vendor names.

I don't see your point. In the example above $(DEB_VENDORS) is created by
dpkg-buildpackage (so not hardcoded) and Ubuntu is the parameter of the
"is_derivative_of()" logical function.

Cheers,
--
Raphal Hertzog

Contribuez Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 04:24 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org