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
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
Reply to: