Re: Bug#397939: Proposal: Packages must have a working clean target
On Sat, Nov 11, 2006 at 10:55:57PM -0600, Manoj Srivastava wrote:
> 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.
Why don't we wait and see if autoconf can manage to go through a half
dozen or so releases without breaking backwards compatibility, first?
And that's assuming we get some kind of commitment from the autoconf
maintainers that they care about backwards compatibility in the first
place.
I just recently had to put in special case hacks in e2fsprogs so it
could support both autoconf 2.59 and autoconf 2.60, and that's why
e2fsprogs is still shipping the generated configure script in the
upstream sources. Fundamentally, I still don't trust autoconf to be
stable in terms of the configure.in constructs which it supports.
- Ted
Reply to: