Re: shared library dependencies (again)

[Gary V.Vaughan <gary oranda demon co uk>]

On Sunday 06 May 2001  5:56 pm, Owen Taylor wrote:
> "Gary V. Vaughan" <gary oranda demon co uk> writes:
> > On Tuesday 01 May 2001  9:15 pm, Owen Taylor wrote:
> > > I think there is a problem with going to libtool-1.4 at this point...

[[snip]]

> > > So perhaps we need to hold off until this is resolved.
> >
> > The patch is a one-liner.

> The obvious patch, as you have it there, is subtly dangerous, because
> it means if you run 'make dist' on a package without re-libtoolizing
> (or running automake -a), then things will break in a confusing
> manner.

That is a pretty minor nit IMHO -- either you are working from CVS and 
running autogen.sh (which runs automake for you), or from a release tarball 
where the packager ran automake for you.  Of the remainder (those people 
working from an already automake'd CVS checkout), some developers may not 
pick up the upgraded dependency on libtool-1.4 (so not applying the patch 
won't hurt) and others will follow the upgrade instructions correctly 
(install libtool-1.4, patch automake...).  There can't be many people left in 
the at risk category at this point?

> But, yes, a similar patch that did version checks probably wouldn't be
> much longer.

I'll make sure libtool 1.4.1 carries such a patch instead of the current one. 
Thanks for the suggestion.

> > If you don't mind having your developers upgrade to libtool-1,4, then
> > asking them to apply this patch isn't too onerous IMHO.  Automake-1.5 is
> > almost certainly several months away.
>
> From personal experience, there is quite a difference between
> installing a new version, and patching your system locally.
>
> With a local patch, you upgrade or switch to a different machine,
> and things start breaking in a confusing manner, and you have
> to remember that a patch was applied, and where it was.

That's true.  I have the luxury of working with a crossmounted /usr/local,
so I hadn't considered that... :-(  In practive, things might not be quite so 
bad, since the next automake upgrade ought to carry the fix to replace the 
patch.

> > Besides, I imagine Debian (and presumably other distros) will soon start
> > shipping libtool-1.4 and a patched automake-1.4.  Perhaps that is a
> > better thing to wait for than automake-1.5?
>
> Well, depends what you mean by shipping....

In the next point release (I hope).

> The availability of packages with the patch certainly helps, and if
> they are standard for the major distributions, even if not shipped,
> that helps too. But generally, I consider depending on patched versions
> of dependencies to be a bad THING, something that puts a significant
> barrier in the way of contributors.
>
> As a last resort, we may go the patch-automake route, since I
> dont' want gtk-python to have to rely on a patched version of
> GTK+ either, but its not something I'm comfortable with.

That's understandable.  If you have no need of interlibrary dependencies, or 
the improved libltdl, or the new ports then waiting seems like the right 
choice.  It would be a pity for this to hold back my patch to port the 
gmodule API to libltdl from libtool-1.4 though...

> [ I've been trying to convince Tom Tromey that he should do a 1.4.1
>   of automake which works with libtool-1.4. No luck so far. ]

Doh!  I hadn't even considered that... I'll volunteer to roll a release for 
him.  Watch this space.

Cheers,
	Gary.
-- 
  ())_.  Gary V. Vaughan     gary@(oranda.demon.co.uk|gnu.org)
  ( '/   Research Scientist  http://www.oranda.demon.co.uk        ,_())____
  / )=   GNU Hacker          http://www.gnu.org/software/libtool   \'      `&
`(_~)_   Tech' Author        http://sources.redhat.com/autobook    =`---d__/