Re: GPL-licensed software linked against libssl on buildds!
Patrick Schoenfeld <email@example.com> writes:
> On Tue, Jan 19, 2010 at 03:40:22PM -0800, Russ Allbery wrote:
>> Because we want our users to be able to patch and rebuild our software
>> to suit their needs. Asking them to set up a chroot build environment
>> is asking quite a lot.
> hu? since when do we have a broader interest in people patching and
> rebuilding packages? I know that there are *some* people interested in
> that (me included) but I don't see that a broader audience wants to
> support that.
Uh, since as long as I've been part of the project. I think this is at
least the third time that I recall the same topic coming up on -devel.
> Apart from this it seems quiet illusionary to support every possible
> circumstance under which a dirty build environment could affect a build.
For the most part, these problems are caused by Autoconf scripts that
automatically detect features during the configure stage of the build.
For the most part, Debian wants to enable all of those features anyway, so
there isn't a serious problem. In the cases where we don't, there is
usually an explicit --disable-X or --without-X flag that can be given to
configure. Where there isn't, that's an upstream bug that is usually
worthwhile to work with upstream to fix.
This really isn't that horribly difficult in most cases. In cases where
it is difficult, Build-Conflicts can be used to ensure a reasonable build
environment when a package would otherwise insist on picking up an
incorrect dependency. In some pathological cases, it may be difficult
enough to not be worth it, but in that case I think it's a wontfix bug,
not a non-bug.
> Bug or not: For the binary packages we provide (which is after all still
> the main priority as a binary distribution) we really want that they are
> built properly in either case. So providing a build environment as clean
> as it could be is really a good thing.
sbuild has never provided this in the history of the project. I really
have to question the emphasis put on this given that we've lived for all
these years without having that and by fixing the packages to do the right
>> People do occasionally test whether packages rebuild properly in dirty
>> environments and file bugs when they don't. Being absolutely certain it
>> will always work is, of course, hard, but I think fixing the bug when we
>> detect it is the right idea, rather than treating it as a bug in the build
> Rebuild tests in dirty environments? I'm aware of rebuild tests in clean
> environments to make sure that build-depends are fine etc. but I never
> heard of such efforts. Could you give a pointer to that?
It was the second hit in Google for the obvious search. There was a long
thread that worked through some of the problems with the initial method of
checking, and there is further discussion of this same question there (why
do we want this, shouldn't we just always use clean build environments,
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>