assumptions about the build environment.
On Fri, Sep 21, 2012 at 08:26:24PM +0100, peter green wrote:
> While working on debian one thing I have not managed to find is
> documentation on what packages can and can't assume about the build
> environment. Does such documentation exist and if not should it be
> Some specific cases i'm wondering about:
> I just discovered that on my beagleboard XM (under armhf sid) nacl
> (which previously build on a debian experimental armhf buildd but
> not a debian unstable armhf buildd) will build if /sys is mounted
> but will not build if it is not mounted. Can packages assume that
> /sys will be mounted in the build environment or not?
I consider /sys almost as essential as /proc. However I wonder
what a build process would need it for.
> IIRC it is generally established that packages are not allowed to
> rely on an internet connection during build but if one is present
> are they allowed to assume it's non-broken.
No, because a 'non-broken' connection would include some particular
hosts being available and there is no way an auto-builder can ensure
that is true.
> I recently came accross
> a package ( sslh ) which fails to build in the presense of nxdomain
> hijacking. Is that a bug?
> Some time ago I found that a package (I think it was openjdk but I
> don't remember for sure) which relied on uname -r such that linux32
> had to be used to build it in an i386 chroot on an amd64. However
> since then I'm pretty sure i've seen similar cases with other
> packages on other architectures being treated as bugs.
I think confusion between kernel vs userland architecture is so
widespread that we should consider this a necessary part of doing a
(It should preferably be fixed upstream, to benefit users who build
from either Debian or upstream source on a 32/64 environment. But I
don't know a simple way to find the 'primary userland architecture'
that is not distribution-specific.)
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com