Re: GPL-licensed software linked against libssl on buildds!
On Tue, Jan 19, 2010 at 04:04:07PM -0800, Russ Allbery wrote:
> > 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.
Wow. How often a topic comes up on -devel is an indicator how
representative a given idea is in the whole developer body?
It might be a sign that the people who want it tend to ask for it
a lot.
> > 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.
Well, I can't tell if most packages use autoconf. Probably they do.
But there are plenty of other build systems around, all with its own
caveats. So my statement "... illussionary to support /every/ possible
circumstance ..." is still true. That does not mean that we shouldn't
fix such bugs if they arise (obviously we should) but having priority
on it is a different thing.
> 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
> thing.
Eh.. what? I'm using sbuild to build my packages before uploading them
locally. It uses schroot and schroot supports LVM snapshots.
Which is what I'm using. Probably it has never been deployed on our
buildds but that has nothing to do with what sbuild can provide.
> >> 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.).
Oh, well, after I read the link I even remember it. Yes, if we are aware
of problems there is reason to fix them. That doesn't mean that we
should always build in dirty chrooots, though.
Best Regards,
Patrick
Reply to: