Re: Bug#397939: Proposal: Packages must have a working clean target
>> 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 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
--
I am deeply CONCERNED and I want something GOOD for BREAKFAST!
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: