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 > created. > > 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? Yes. > 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 native build. (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.) Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120921200757.gf29...@decadent.org.uk