[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

On Wed, Jan 20, 2010 at 10:37:48PM +1300, Lucas Nussbaum wrote:
> > 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, the build process is likely to be very
> similar on your system and on the buildds.

This "very likely" and $2 buys you a cup of coffee.  I have seen cases of
build-dep skew across architectures resulting in binaries in the archive
with different dependencies.

> It's true that that isn't a full guarantee (differences between
> archs, binNMUs done later in the package lifecycle),

binNMUs are a non-negligible use case.  I've seen packages end up with wrong
dependencies across binNMUs due to this issue as well.

> but clean chroot environments offer much more guarantee than the current
> situation, which is based only on the maintainer disabling all unused
> options or adding all the proper build-conflict.

No, *neither* is a guarantee, which is why it's warranted to use *both*
approaches to minimize the occurrence of bugs.

Suppose that libcups2-dev adds a dependency on libssl-dev, because it starts
to provide two versions of libcups - the default lib still using gnutls, and
an alternative lib linked against openssl.  The majority of packages will
get no new dependencies, because libcups.so will still link against gnutls;
but netatalk will wind up with a dependency on openssl and will be RC buggy
as a result.

Where does the bug lie, and when did it appear?  Is it a bug in libcups-dev
for depending on libssl-dev?  No, no one would insist that the cups
maintainer revert this change (at least not for this reason).  Is it a bug
in the maintainer for not having checked first that no reverse-deps build in
wrong ways as a result of this change?  Well, that's at least as hard and
error-prone as doing more general unclean-chroot checks, if not moreso.

No, the bug is in the netatalk package for building differently when
different packages are installed.  The severity of the bug may vary over
time, but it's already latent in the package before the cups maintainers
make their change.

The operative principle that's been in place since Build-Depends and
Build-Conflicts were first formulated was that these + build-essential
should provide *all* the information needed for package builds to be
reproducible.  We may fall short of that standard from time to time, but
that's not a reason to abandon as unsupported anyone building packages in an
environment other than an empty chroot.

> That is hard and error-prone::

Yes.  But I don't think this is a reason to abandon the principle,
especially given the class of bug described above.

Anyway, if you're going to insist that everyone do all their builds in clean
chroots, I could just as well insist the opposite - that everyone build all
their packages in cluttered chroots, to ensure no missing Build-Conflicts.

> among the packages you maintain, for example, sqsh picks up an additional
> dep on tcl8.4 if tcl-dev is installed.

Oh, thanks for the info.  This seems to be due to a namespace collision
between tcl-dev and a commercial library that sqsh supports building
against; I'll add a build-conflicts.

And I don't think the existence of bugs in my packages disproves my
argument. :)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: