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