Re: Packages which build-depend on libtool1.4
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
Reply to: