On Thu, Sep 18 2008, Goswin von Brederlow wrote: >>Russ Allbery <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://www.golden-gryphon.com/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]