Re: assumptions about the build environment.
On Sat, Sep 22, 2012 at 07:06:57PM +0200, Adam Borowski wrote:
> On Sat, Sep 22, 2012 at 04:28:32PM +0200, Wouter Verhelst wrote:
> > On Sat, Sep 22, 2012 at 12:23:36AM +0200, Kurt Roeckx wrote:
> > > They probably should try to use the output of dpkg-architecture to
> > > select the arch. Then should never check that output of uname -m.
> >
> > That's living on the assumption that there's never any upstream build
> > system which is both complex (thus difficult to patch correctly) and
> > relying on uname -m in one or more places. I'm not saying we should
> > necessarily support such systems, but if running inside something akin
> > to linux32 is not causing too many problems, it would make that easier.
> > What's the harm?
>
> That it breaks multiarch builds.
Multiarch builds are not done on our buildd machines.
> You'd need a separate chroot for every arch you want to be able to compile
> for.
Buildd machines typically have only one chroot for each distribution
they build, as they don't build for multiple architectures.
[...]
> As for complex "hard to patch" build systems, could you give me an example?
> 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.
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.
--
The volume of a pizza of thickness a and radius z can be described by
the following formula:
pi zz a
Reply to: