Re: GPL-licensed software linked against libssl on buildds!
Lucas Nussbaum <lucas@lucas-nussbaum.net> writes:
> On 19/01/10 at 16:04 -0800, Russ Allbery wrote:
>>>> 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 environment.
>>> 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?
>> http://lists.debian.org/debian-devel/2008/01/msg00869.html
>> 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, etc.).
> Yes, and this never resulted in any bug filing as far as I remember, due
> to the number of bugs I would have had to file.
I've seen bugs filed by other people for dirty build environment problems,
but I suspect they were mostly one-offs. Sorry to have implied it was
directly related to your effort.
> There are two ways to attack that problem:
> (1) We decide that we want to provide the guarantee that packages build
> the correct way in unclean envs. That mean making such bugs RC,
> basically, and making efforts to find such bugs.
> (2) We decide that it would be nice if packages don't do too crazy
> things when built in unclean envs, but provide no guarantee, and
> recommend the use of pbuilder and schroot + tarballs/lvm when people
> need guarantees.
> The current situation, where we don't do (1), but still build the
> packages we provide in unclean envs, is not an acceptable compromise
> (especially now that we have the technical means to solve that issue).
> It means that some packages in the archive are silently being built with
> additional deps, without any coordinated effort to track them down.
> Of course, I'm in favor of doing (2) and building in clean envs on our
> own buildds. But we could do (1), and spend a lot of time on this
> nit-picking project. Might be "fun".
For the record, (2) is what I'd prefer as well, although I'm not sure (1)
is as big of a problem as that. But I do agree with the idea that we want
to simultaneously improve the reliability of our binary packages and fix,
where possible, bugs in building our source packages in other than
pristine environments.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: