On Sat, 11 Nov 2006 22:55:57 -0600, Manoj Srivastava <[EMAIL PROTECTED]> said:
>>> On Sat, 11 Nov 2006 13:52:06 +0000, Stephen Gran
>>> <[EMAIL PROTECTED]> 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
DO. DO DAMMIT FINGERS, IT'S DO!!!!!
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.
manoj
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 <[EMAIL PROTECTED]> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
