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.
One thing that is at least documented in policy is that the only packages that it can rely on being installed are essential, build-essential and the packages's build-depends. > 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? As far as I know, on all the buildds /sys, /proc, /dev/pts and /dev/shm are available and we get complaints if some of them aren't there. At least /proc and /dev/pts will frequently results in errors, I think there are also at least some packages that require /dev/shm/. I don't remember anything about /sys. I think it would also be a good idea to have this documented in policy if it's not already. > 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. I recently came accross > a package ( sslh ) which fails to build in the presense of nxdomain > hijacking. Is that a bug? It basicly comes down to if they try to download something as source to be build. In that case it's clearly a violation of policy because the source is not in the archive. Some packages then fall back to the source file that's in the package, but they should have always used that in the first place. I know there are also some packages that have a test suite that connects to something on the internet. This doesn't result in changes to the binaries, it just checks that it works properly. You can argue wheter that should be allowed or not, or that the test server should run on localhost. In any case packages doing that shouldn't fail to build because of that and should just skip that test in case the network is down. > 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. They probably should try to use the output of dpkg-architecture to select the arch. Then should never check that output of uname -m. On the buildds we work around this by using linux32 because there were a lot of packages that were broken, and it was easier to work around it. Maybe we should stop doing that. Kurt -- 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/20120921222336.ga31...@roeckx.be
