Re: GPL-licensed software linked against libssl on buildds!
- To: Lucas Nussbaum <email@example.com>
- Cc: firstname.lastname@example.org
- Subject: Re: GPL-licensed software linked against libssl on buildds!
- From: Wouter Verhelst <email@example.com>
- Date: Tue, 2 Feb 2010 01:07:40 +0100
- Message-id: <[🔎] 20100202000740.GG22855@celtic.nixsys.be>
- In-reply-to: <20100120093748.GA23217@xanadu.blop.info>
- References: <1263929465.1812.21.camel@beppo> <firstname.lastname@example.org> <20100120002428.GA30088@xanadu.blop.info> <email@example.com> <20100120012233.GA376@xanadu.blop.info> <20100120084824.GA11028@dario.dodds.net> <20100120093748.GA23217@xanadu.blop.info>
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
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.