GPL-licensed software linked against libssl on buildds!
On Tue, Feb 02, 2010 at 07:59:53AM +0100, Lucas Nussbaum wrote:
> On 02/02/10 at 01:07 +0100, Wouter Verhelst wrote:
> > 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.
> ... but I question that it is a bug that we want to spend time fixing.
> > - 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.
> I think that the question is whether we would rather have the maintainer
> spend time fixing those issues, or the buildd spend time dealing with
> the consequences of using LVM snapshots.
The crux of the problem is that we can provably build all packages
in a clean minimal chroot, at the expense of not necessarily having
all potential Build-Conflicts identified. If we build in a dirty
chroot, we might potentially trip up over the odd missing Build-
Conflict, but we can't prove that they are correct unless we test
building with /every/ possible combination of additional packages
(which is not practical, and wastes a lot of CPU time for little to
no real benefit). i.e. we can have provably correct Build-Depends,
but realistically /not/ Build-Conflicts.
The whole point of Build-Depends/Conflicts is to be able to reliably
build a package. If we start from a clean state, the need for
Build-Conflicts is no longer there, except for things the developer
notices on their system. It's just not worth the developer time
to identify potentially conflicting packages if they aren't a
problem in reality, and by starting from a clean slate we effectively
reduce the need for Build-Conflicts altogether.
> I personally think that if we have a way to use CPU time to solve a
> problem that would require maintainer time otherwise, we should use it.
Well, from my experience, LVM snapshots use /less/ CPU time than
plain chroots. sbuild needs to clean up the chroot after a build,
and this means removing all of the build-deps installed at the
start. This can take a lot of time, certainly much more than the
time taken to delete a snapshot. snapshots are copy-on-write,
which makes creation very fast, and deleting them is similarly
quick (and we completely skip the chroot cleanup). The obvious
advantage is that cleanup can fail, and leave the chroot in a dirty
state; snapshots guarantee an identical initial state for every build.
In short, starting each build from a known clean "base" chroot
is not an additional overhead in any cases I've seen.
We also have the ability to use unionfs/aufs in place of snapshots,
which are perhaps even more lightweight. And once we have btrfs
subvolume snapshots (work in progress), they will be even more
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.