Re: GPL-licensed software linked against libssl on buildds!

[Wouter Verhelst <wouter@debian.org>]

On Wed, Jan 20, 2010 at 10:37:48PM +1300, Lucas Nussbaum wrote:
> On 20/01/10 at 00:48 -0800, Steve Langasek wrote:
> > On Wed, Jan 20, 2010 at 02:22:33PM +1300, Lucas Nussbaum wrote:
> > 
> > > Why spend a lot of time on tasks that provide little benefit, and also
> > > some disadvantages (in some cases, the fixes might be non-obvious, and
> > > requires changes to the packaging that tend to obscure it, for example
> > > by using --disable-foo for each and every option we don't want)?
> > 
> > I'm not asking anyone to spend time on this task, but I still consider
> > missing build-conflicts a bug.  Ignoring these bugs by insisting on clean
> > chroot environments for all official package builds is no solution - what if
> > one of your build-dependencies pulls in one of these other packages,
> > resulting in an undistributable (license-incompatible) misbuild?  If the
> > build-conflicts had been declared, or if the --without-foo option had been
> > passed, we would not have to worry about such a misbuild.
> 
> If the chroot env is clean,

I hate to break the news, but no build environment (look, full word) is
ever clean. There are environment variables, other processes running on
the same system, and various other things that can influence it.
Granted, rogue environment variables are rarely going to be a problem on
a buildd host, but clock skew or rogue processes from previous builds
might not be. Okay, that's a stretch. Still.

At any rate, here are some facts:
- A package that builds differently because something is (or is not)
  installed on the build system is buggy. Period. It has nothing to do
  with the build system, it's the package.
- When a package has a buggy debian/rules and/or debian/control file,
  and it gets built on 11 architectures, surely one of those
  architectures is going to hit that bug.
- A clean chroot takes time and processing power. You need to drop and
  recreate the chroot between builds, upgrade the same Build-Essential
  packages every time you do an upgrade, copy the apt cache in and out
  of the chroot (or keep downloading the same packages over and over),
  and various other things. LVM snapshots fix some, though not all, of
  those problems, and introduce a few of their own.
  I don't know about you, but I'd rather have the buildd spend
  processing power on building packages. Having it fail at producing a
  good package because the maintainer didn't do a good enough job is
  nothing new -- they do that all the time.

As such, I'm rather unconvinced of the merits of this LVM snapshot
thing...

-- 
The biometric identification system at the gates of the CIA headquarters
works because there's a guard with a large gun making sure no one is
trying to fool the system.
  http://www.schneier.com/blog/archives/2009/01/biometrics.html