Re: 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
> 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
Reply to: