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 dpkg

 
 
LinkBack Thread Tools
 
Old 09-11-2008, 05:53 PM
Russ Allbery
 
Default Bug#489771: New Build-Options field and build-arch option, please review

Raphael Hertzog <hertzog@debian.org> writes:
> On Wed, 10 Sep 2008, Bill Allombert wrote:

>> I like to say I concurr with Russ. There are some much difference
>> between packages that distributions wide default does not make sense.
>> Such change would rather lead me to hardcode values of
>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>
> But more and more people want to be able to change distribution wide
> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> other want to be able to enable hardening options by default and I agree
> with them that official support for such a facility is desirable.

So they should set DEB_BUILD_OPTIONS in the environment. That's what it's
for. I don't have any objections to that, or even to doing it via
dpkg-buildpackage.

My objection is specifically to having dpkg-buildpackage set a variety of
environment variables *by default*, and then telling package maintainers
that they should rely on those environment variables being set in the
default case. That breaks the debian/rules interface and requires that
all package builds go through dpkg-buildpackage. Having dpkg-buildpackage
set environment variables in the non-default case like Emdebian is not a
problem, since for Emdebian builds (for example) Emdebian can decide that
using dpkg-buildpackage or setting the environment variables manually is
required. There is no existing precedent, and they can make that rule
from scratch.

My concern is for the default build where there *is* an existing precedent
that debian/rules build should work sanely, not for support for special
cases like that where the existing debian/rules interface already doesn't
do the right thing without additional help.

If you are going to go down this path of having dpkg-buildpackage set up
an environment that package maintainers should rely on, you or someone
else on the dpkg team needs to make a debian-devel-announce post making it
clear that debian/rules build is no longer a supported interface for
building packages and using dpkg-buildpackage is required for consistent
behavior.

Right now, I don't think most Debian Developers have any idea what the
implications of these changes are.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-18-2008, 01:03 PM
Goswin von Brederlow
 
Default Bug#489771: New Build-Options field and build-arch option, please review

Russ Allbery <rra@debian.org> writes:

> Raphael Hertzog <hertzog@debian.org> writes:
>> On Wed, 10 Sep 2008, Bill Allombert wrote:
>
>>> I like to say I concurr with Russ. There are some much difference
>>> between packages that distributions wide default does not make sense.
>>> Such change would rather lead me to hardcode values of
>>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
>>
>> But more and more people want to be able to change distribution wide
>> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
>> other want to be able to enable hardening options by default and I agree
>> with them that official support for such a facility is desirable.
>
> So they should set DEB_BUILD_OPTIONS in the environment. That's what it's
> for. I don't have any objections to that, or even to doing it via
> dpkg-buildpackage.

Setting the environment on a distribution wide level is ugly and
fragile. Too many users will reset the environment in their .bashrc.

Instead the idea was to have a vendor (set in
/etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.

The bugreports relevant for this have 2 solutions:

1) make dpkg-buildpackage use (or tool with equivalent environment
setting up capabilities) mandatory

2) have debian/rules call something to set DEB_VENDOR and possibly
more

E.g. 'include /usr/share/dpkg/Makefile.dpkg'
or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR)
DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)

The argument against 2 is that is requires every source to be modified
if they want to support vendors whereas 1 only needs some small
modification to dpkg-buildpackage to support calling arbitrary targets
in debian/rules and a change in policy making its use mandatory.

> My objection is specifically to having dpkg-buildpackage set a variety of
> environment variables *by default*, and then telling package maintainers
> that they should rely on those environment variables being set in the
> default case. That breaks the debian/rules interface and requires that
> all package builds go through dpkg-buildpackage. Having dpkg-buildpackage
> set environment variables in the non-default case like Emdebian is not a
> problem, since for Emdebian builds (for example) Emdebian can decide that
> using dpkg-buildpackage or setting the environment variables manually is
> required. There is no existing precedent, and they can make that rule
> from scratch.

Then you have one interface for Debian and one interface for every
other vendor including ubuntu (or option 2 above).

> My concern is for the default build where there *is* an existing precedent
> that debian/rules build should work sanely, not for support for special
> cases like that where the existing debian/rules interface already doesn't
> do the right thing without additional help.
>
> If you are going to go down this path of having dpkg-buildpackage set up
> an environment that package maintainers should rely on, you or someone
> else on the dpkg team needs to make a debian-devel-announce post making it
> clear that debian/rules build is no longer a supported interface for
> building packages and using dpkg-buildpackage is required for consistent
> behavior.

Plus a note in policy clarifying that debian/rules is only an
interface for dpkg-buildpackage but not users.

> Right now, I don't think most Debian Developers have any idea what the
> implications of these changes are.

I have to say i verry rarely do not use debuild. And 99% of the
exceptions are calling debian/rules clean.

MfG
Goswin

PS: with dpkg-buildpackage setting env vars like it does now you
already have a verry confusing situation.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-18-2008, 01:35 PM
Bill Allombert
 
Default Bug#489771: New Build-Options field and build-arch option, please review

On Thu, Sep 18, 2008 at 03:03:20PM +0200, Goswin von Brederlow wrote:
> Russ Allbery <rra@debian.org> writes:
>
> > Raphael Hertzog <hertzog@debian.org> writes:
> >> On Wed, 10 Sep 2008, Bill Allombert wrote:
> >
> >>> I like to say I concurr with Russ. There are some much difference
> >>> between packages that distributions wide default does not make sense.
> >>> Such change would rather lead me to hardcode values of
> >>> DEBIAN_BUILD_OPTIONS in debian/rules if they are used blidly.
> >>
> >> But more and more people want to be able to change distribution wide
> >> default: Emdebian wants to enable "nodocs" and "nocheck" by default,
> >> other want to be able to enable hardening options by default and I agree
> >> with them that official support for such a facility is desirable.
> >
> > So they should set DEB_BUILD_OPTIONS in the environment. That's what it's
> > for. I don't have any objections to that, or even to doing it via
> > dpkg-buildpackage.
>
> Setting the environment on a distribution wide level is ugly and
> fragile. Too many users will reset the environment in their .bashrc.
>
> Instead the idea was to have a vendor (set in
> /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
> unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.
>
> The bugreports relevant for this have 2 solutions:
>
> 1) make dpkg-buildpackage use (or tool with equivalent environment
> setting up capabilities) mandatory
>
> 2) have debian/rules call something to set DEB_VENDOR and possibly
> more
>
> E.g. 'include /usr/share/dpkg/Makefile.dpkg'
> or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR)
> DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)
>
> The argument against 2 is that is requires every source to be modified
> if they want to support vendors whereas 1 only needs some small
> modification to dpkg-buildpackage to support calling arbitrary targets
> in debian/rules and a change in policy making its use mandatory.

2) is the right way to proceed for _Debian_. People in a hurry can use 1,
but not us.

2) imply that packages will not have DEB_VENDOR support unless some
check they support it.

> > Right now, I don't think most Debian Developers have any idea what the
> > implications of these changes are.
>
> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
directly.

Cheers,
Bill.


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-18-2008, 02:48 PM
Manoj Srivastava
 
Default Bug#489771: New Build-Options field and build-arch option, please review

On Thu, Sep 18 2008, Goswin von Brederlow wrote:
>>Russ Allbery <rra@debian.org> writes:
> Setting the environment on a distribution wide level is ugly and
> fragile. Too many users will reset the environment in their .bashrc.
>
> Instead the idea was to have a vendor (set in
> /etc/dpkg/origins/default) that will be exported into DEB_VENDOR if
> unset and also set DEB_BUILD_OPTIONS to the vendor specifics defaults.
>
> The bugreports relevant for this have 2 solutions:
>
> 1) make dpkg-buildpackage use (or tool with equivalent environment
> setting up capabilities) mandatory
>
> 2) have debian/rules call something to set DEB_VENDOR and possibly
> more
>
> E.g. 'include /usr/share/dpkg/Makefile.dpkg'
> or 'DEB_VENDOR ?= (shell dpkg-vendor -qDEB_VENDOR)
> DEB_BUILD_OPTIONS ?= (shell dpkg-vendor -qDEB_BUILD_OPTIONS)
>
> The argument against 2 is that is requires every source to be modified
> if they want to support vendors whereas 1 only needs some small
> modification to dpkg-buildpackage to support calling arbitrary targets
> in debian/rules and a change in policy making its use mandatory.

But you need to modify the rules file anyway to take advantage
of the DEB_VENDOR variable, no? Currently, setting it does nothing for
any package. So if people are changing the rules file, they can also
add in those two lines.

>> My objection is specifically to having dpkg-buildpackage set a
>> variety of environment variables *by default*, and then telling
>> package maintainers that they should rely on those environment
>> variables being set in the default case. That breaks the
>> debian/rules interface and requires that all package builds go
>> through dpkg-buildpackage. Having dpkg-buildpackage set environment
>> variables in the non-default case like Emdebian is not a problem,
>> since for Emdebian builds (for example) Emdebian can decide that
>> using dpkg-buildpackage or setting the environment variables manually
>> is required. There is no existing precedent, and they can make that
>> rule from scratch.

I tend to agree.

> Then you have one interface for Debian and one interface for every
> other vendor including ubuntu (or option 2 above).


>> My concern is for the default build where there *is* an existing
>> precedent that debian/rules build should work sanely, not for support
>> for special cases like that where the existing debian/rules interface
>> already doesn't do the right thing without additional help.

>> If you are going to go down this path of having dpkg-buildpackage set
>> up an environment that package maintainers should rely on, you or
>> someone else on the dpkg team needs to make a debian-devel-announce
>> post making it clear that debian/rules build is no longer a supported
>> interface for building packages and using dpkg-buildpackage is
>> required for consistent behavior.

I see that as a serious degradation in the quality of the
distribution.

> Plus a note in policy clarifying that debian/rules is only an
> interface for dpkg-buildpackage but not users.

No. Debian is a member of the free software community, and being
able to just do a configure, or a build, or build a single binary, by
end users, is a feature that should not be given up easily. And
certainly not without some significant rationale; degrating features
for most of our users to cater to other distributions does not actually
cut it.

>> Right now, I don't think most Debian Developers have any idea what the
>> implications of these changes are.

> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

I have never ever used debuild. So there is another anecdote,
which may or may not mean anything.

manoj
--
"Nothing can stop him. Not even common sense." Mark Komarinski
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-18-2008, 07:08 PM
Russ Allbery
 
Default Bug#489771: New Build-Options field and build-arch option, please review

Goswin von Brederlow <goswin-v-b@web.de> writes:

> Plus a note in policy clarifying that debian/rules is only an
> interface for dpkg-buildpackage but not users.

Right. If you want to make this a rule, then we should discuss it, reach
a consensus, document and publicize the change, and so forth.

Right now, I feel like this change is being made as part of dpkg
development, without general recognition of what's happening and without
the corresponding changes to Policy so that DDs know what to expect. (I
don't think this is *intentional* on your part, more a case of a set of
decisions that all seemed like a good idea at the time but which
cumulatively have a significant impact.)

> I have to say i verry rarely do not use debuild. And 99% of the
> exceptions are calling debian/rules clean.

The hard part of standards isn't the common case. Currently, debian/rules
is defined as the package build interface, and while most people don't
normally rely on that, we don't know what might break; one of the points
of a standard is to let people rely on it without having to tell you first
what they're doing.

Personally, I use debian/rules build all the time for testing, and would
never have thought to mention it to anyone.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 09-18-2008, 07:23 PM
Bill Allombert
 
Default Bug#489771: New Build-Options field and build-arch option, please review

On Thu, Sep 18, 2008 at 05:36:46PM +0200, Raphael Hertzog wrote:
> On Thu, 18 Sep 2008, Bill Allombert wrote:
> > > I have to say i verry rarely do not use debuild. And 99% of the
> > > exceptions are calling debian/rules clean.
> >
> > Precisely, debuild does not use dpkg-buildpackage, but call debian/rules
> > directly.
>
> This has been fixed already. It calls dpkg-buildpackage now (except if you use
> its hook features).

So it still call debian/rules directly in some case.

> (And I don't see why one way would be more Debianish than the other)

Neither I do, but then I do not attempt to kill one way in favour of the other.

I would object to a proposal policy making dpkg-buildpackage mandatory
to build packages.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.


--
To UNSUBSCRIBE, email to debian-dpkg-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 12:51 AM.

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