Re: New Build-Options field and build-arch option, please review
On Mon, Jul 14, 2008 at 01:22:58PM -0700, Russ Allbery wrote:
> Raphael Hertzog <hertzog@debian.org> writes:
>
> > I think we're already on that path for quite some time. If your package
> > uses DEB_(BUILD|HOST)_* variables, you rely on dpkg-buildpackage setting
> > them for you (with dpkg-architecture).
>
> I most certainly do not rely on dpkg-buildpackage setting anything. I
> call dpkg-architecture directly, which is also what's in our best practice
> documents.
>
> DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
>
> I would consider packages that didn't do that and just assumed that those
> variables were already set to be buggy.
>
> > The same is expected with default values of builder/linker flags now
> > that dpkg-buildpackage provides reasonable defaults.
>
> Yeah, that bothered me too. I made a perhaps poor tactical decision to
> not fight about it since it seemed that it had a lot of momentum and I
> couldn't think of specific problems other than the one that we ran into.
> But this is going beyond setting some defaults that are already set in
> nearly all of our packages.
>
> > So yes, I'm somehow building on this model where dpkg-buildpackage can
> > simplify the work of packager by providing some distribution-wide
> > reasonable defaults.
> >
> > People have noticed that and already requested that we can call arbitrary
> > targets of debian/rules with all the proper initialization done precisely
> > for test purpose during packaging work (see #477916).
>
> I must say, I really do not like this direction. debhelper and cdbs and
> similar sytsems are the places to provide this help where people want to
> use it, in my opinion. We have a lot of past experience with that and we
> have the compatibility level to handle smoothing transitions. (And to
> provide a way for people to never transition, I admit, and I see where
> that's the problem that you're solving, but I prefer that problem to the
> problems introduced by the instability of having the package build
> infrastructure change the input to the builds without coordination with
> the package.)
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.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: