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

Re: Proposed Autoconf 2.50 path



On Sat, May 26, 2001 at 12:33:24PM +1000, Anthony Towns wrote:
> I'm thinking it's about time we started making our autobuilders "just
> cope" with packages that happen to not cope with the latest changes in
> gcc3, libtool, autoconf and whatever other toolchain things have changed.

This is the slippery slope, and if we start to go down on that we will never
know what builds and what not and if it builds, and how the build was done.
We will not record it for the people who will have to continue our work.
The "toolchain things" are the main reason for build problems, and it is
important to be aware of them and report them.  As an example, the Hurd only
works well with very early libtool versions and >= 1.3.5-5.  It is quite
annoying, because older versions are still in common use.  But I very much
prefer to file bug reports for these instead just force an update of libtool
in the autobuilder.  I don't want to answer all those questions how a
specific package was build, esp as I might not even know.

The lesson to learn here is that packages should not require libtool,
autoconf, or whatever at build time.  Those tools are designed to be run at
source preperation time, so it is the responsibility of the package
maintainer to run them before packaging the source.

Of course, this does not fit well with the home-made patch systems (if
configure.in and friends are patched), will uglify the debian diff and
what not other strings are attached to it.  But it is usually the right
thing to do.

For packages which have extensive and dynamic patches, we don't have a good
solution.  Compared to the actual size of the distribution, I think the
number is not so huge.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de



Reply to: