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

Re: 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

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

"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

Reply to: