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

Re: Bug#397939: Proposal: Packages must have a working clean target

On Sat, 11 Nov 2006 22:55:57 -0600, Manoj Srivastava <srivasta@debian.org> said: 

>>> On Sat, 11 Nov 2006 13:52:06 +0000, Stephen Gran
>>> <sgran@debian.org> said:
>>> > It would be nice if we could support all sorts of forms of
>>> > rebuilds, but in practice, what we tend to take seriously is the
>>> > sort of FTBFS bugs that will affect the autobuilders.  Since
>>> > they build from an intermediate form generated by Debian
>>> > developers (debian/rules), I am not sure how much we should
>>> > worry about other use cases.
>>> I think we should worry a lot about other sue cases, or give up
>>> the pretense that we are a free software distribution.  The
>>> buildds are just delivering a binary only distribution to the end
>>> users; the free part comes from delviering source cod4e that our
>>> end users can tweak and modify and rebuild from.
>>> Policy should not be just concerned with releases and delivering
>>> binary packages, but with the overall goals of the distribution as
>>> a free software project.

>> I think I haven't made myself clear, if you're reading that from
>> what I wrote.  What I mean is, we frequently see "I'm rebuilding
>> the archive, and your package FTBFS", and we all say fine, no
>> problem, let's fix the bug.  If someone comes along and say "I'm
>> reautotooling the entire archive, and your package FTBFS", I might
>> be inclined to ask why they wanted to do something like that.  The
>> autotools have been until recently fairly fragile.  Macros that
>> worked with autoconf2.13 don't work with autoconf2.5x and vice
>> versa.  Unless you constantly rework the .am and .ac files to keep
>> pace with upstream autotools changes, then occasional breakage
>> isn't so much a bug as expected behavior.

>         OK. But that was a tool chain transition, and needs be
>         treated
>  like any other tool chain transition -- even though we can hide the
>  debris arising from such a transition by shipping intermediate
>  files.

>> I'm not arguing for being opaque, or eliding real problems in favor
>> of a fast release.  I am just mentioning in passing that redoing
>> your build system on the fly mid-build can be expected to have a
>> few hiccups.  We frown on autogenerated debian/control's for
>> similar reasons, right?

>         Yes, but we don't frown upon autogenerated .o files. And


        Yes, and we do frown upon autogenerated .o files. 

>  lex, swig, and yacc output files are also not pre-generated,
>  usually.

>         What you are saying, in essence, is that we have not been
>  treating autoconf transitions with the care we devote to other
>  transitions; and as a result people have started shipping
>  intermediate files.

>         While I recognize these past lapses, I am not sure why we
>  should condone and in the future pander to them -- I am hoping that
>  autotools are coming of age, and there shall be few major API
>  changes in the future. Post etch, perhaps we can evaluate if
>  overhauling our autotools usage in Debian to allow treating
>  autoconf like we do lex and yacc -- and building from sources -- is
>  feasible, or not.

one of these days my fgingers are gonna get me into big trouble
The bland leadeth the bland and they both shall fall into the kitsch.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: