Re: assumptions about the build environment.
+++ Wouter Verhelst [2012-09-24 13:14 +0200]:
> On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote:
> >
> > That it breaks multiarch builds.
>
> Multiarch builds are not done on our buildd machines.
Yet. They very likely will be soon, for partial architectures and
cross-toolchains.
And we still want them to work, in cross-compiling configurations,
too, at least for core stuff.
> [...]
> > As for complex "hard to patch" build systems, could you give me an example?
apache/apr :-)
But the case of uname _is_ easy to deal with - use dpkg-architecture.
And on the original point, anything checking /sys for HOST arch stuff
is likely to be getting it wrong too - fine for BUILD arch checks.
> > I can't quite think of a case where patching references to uname could be
> > tricky.
>
> I can't give you an example of *this* particular issue; but given the
> amount of complex build systems I've seen, I don't think it's too
> unreasonable to assume they exist.
>
> I'm not saying we should change policy to mandate that i386 builds in
> i386 chroots should be done with linux32 running or something similar.
> But I also do happen to think that tuning buildd machines to do a bit
> more than what policy requires them to do is usually a good thing. For I
> used to keep debhelper installed in my buildd chroots, even though it's
> not part of build-essential; but since almost all packages use it in
> some form or another, it was being installed and deinstalled enough that
> I could gain some time by having it installed by default. The result
> was of course that packages who mistakenly failed to add debhelper to
> their build-depends would successfully build on my buildd hosts, but I
> didn't think that was much of a problem.
>
> Similarly, if adding linux32 to the environment on amd64 hosts building
> inside a chroot means the success rate for packages built will go up, I
> don't think we should refrain from doing so -- unless, of course, doing
> so would cause more problems than it would solve, which was the point of
> my question.
Well, this is indeed exactly the point. If we specify what can be
assumed by packages, but then actually don't test that, we test
something slightly different (by putting extra stuff int he
environment by default) then bugs will not be found.
It's a simple tradeoff between rigour and build success/hassle. In
general I like the rigour in Debian and have spent the last year or so
being rigourous in cross-building/multiarch stuff which has found an
awful lot of (expected) breakage. (You an gloss over a lot of stuff by
installing qemu in chroots when cross-building, for example, and often
it's the best thing to do)
In general I'm in favour of agreeing what can be relied upon and
then only providing that in buildds. But you are quite right that for
the purposes of buildds doing native building this improves your
success rate by glossing over potentially-dubious checks, with little
cost.
> After all, the autobuilder network is not meant to do QA; we have
> resources for doing full-archive rebuilds for that purpose. Instead, the
> autobuilder network is meant to make sure we build as many packages as
> possible. If we can avoid some issues in building packages that isn't
> really worth spelling out in policy by just doing some minor
> configuration tweak on a buildd host, I think we should do so -- and
> this certainly qualifies, IMO.
I only run cross-buildds, not native ones, so this isn't my call. Just
bear in mind that every such choice of providing more than is strictly
mandated will be hiding bugs in other circumstances.
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: