On Friday 18 March 2005 23:55, Kurt Roeckx wrote: > On Fri, Mar 18, 2005 at 10:27:53PM +0100, David Schmitt wrote: > > On Friday 18 March 2005 19:37, Kurt Roeckx wrote: > > > One of my goals for etch is getting rid of all old libtool > > > versions. > > > > > > I'm still wondering on how exactly I'm going to do this. But I > > > am thinking about getting all those packages to build depend on > > > libtool, autoconf and automake. > > > > $ grep $package/ltmain.sh VERSION > > > > But perhaps it'd be better to code some lintian/linda checks for that? > > I do know on how to identify which version of libtool was used in > the Package. That has nothing to do with how to avoid having > packages build using a broken version of libtool.
Sorry, I didn't properly parse your statement. Frank showed me the light. > There are several ways of getting all of them to the latest > debian version. > > One way to do it would be to update all the files and just > put them in the diff. This basicly is a one time only solution. > This also makes it likely that on the next upstream version we'll > get the same old versions again. This is something we really > would like to avoid. > > An other way to do it is to do the update at build time. This > requires build depending on auto tools. This has a few > advantages including that the diff is smaller and more readable, > should give porters of a new port less problems since they can > make sure they have a fixed version. An other advantage is that > we really avoid timestamp skew issues you might have with the > first, but dpkg-source is supposed to fix those soon now. > > Also see the thread on debian-devel (automake/autoconf in > build-dependencies) for more information about the same subject. I read it, but still haven't made my mind up on that one. Still I think a lintian/linda check on old versions of auto* and libtool stuff would be a nice start. This would enable easy finding of problematic packages via http://lintian.debian.org/reports/tags.html , alert maintainers of troublesome packages as well as preventing regressions via new upstream versions containing the old stuff. But B-D'ing and updating in build: would then need an override if the update is done at build time. That's probably not so good. Regards, David -- - hallo... wie gehts heute? - *hust* gut *rotz* *keuch* - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
