libtool
[Top][All Lists]
Advanced

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

Re: support parallel installations [libtool--release--2.0--patch-68]


From: Gary V. Vaughan
Subject: Re: support parallel installations [libtool--release--2.0--patch-68]
Date: Tue, 23 Nov 2004 16:19:48 +0000
User-agent: Mozilla Thunderbird 0.9 (X11/20041103)

Hi Daniel,

Daniel Reed wrote:
>
> ) But we shouldn't be in the business of forcing upgrades.  I'd
> ) rather give people the option, and autoreconf directories myself
> ) if the maintainer isn't providing a build option or platform I
> ) need.  The jury is still out as to whether we will have it in
> ) the next major release (i.e in a year or so).
> 
> So long as the package does cleanly autoreconf, sure! My problem with
> parallel installs is just that it seems to only be used to allow software
> packagers to keep their [broken] build control files from being changed to
> work with the newer tools.

True, although I haven't (yet) come across anything that can't be fixed
with ten minutes of configure.in hacking and 30 minutes of waiting for
autoreconf to run (:-b).

> If, whenever a syntax change is introduced in 2.0, a new 1.5 would be
> released with the new syntax and warnings attached to the [still-functional]
> old syntax? The functional behavior could stay the same but the packagers
> would at least find out about the potential packaging problems and fix them
> incrementally. I just don't want to have to get in the situation I am with
> Automake, which is to still be supporting the 5+ year-old Automake 1.4
> because some software does not tool in anything newer.

I don't think 1.5.x compatibility releases would help.  If packagers are
refusing to upgrade because they can't deal with better warnings, then
they will still refuse to upgrade even if the release is called 1.5.x
instead of 2.x.  Our plan is to put the syntax compatibility directly
into libtool 2.x, so that (properly quoted) old configure.{in,ac} will
continue to work with libtool 2.x, or can be autoupdated.

Do you have people who actively hold back to ancient releases?  Or are
they too busy with their software to worry about changing the build
system when it appears to work anyway?  If the latter, I would be
surprised if they turned away a patch to their Makefile.ams and
configure.ac along with instructions of how to autoreconf.  Especially
if you ask them to do this because of a real bug you have encountered
in their shipped config.

I would have thought that as a packager you would find parallel installs
of libtool to be a boon... with several versions installed you could
edit a package's configure.ac and rerun the same libtool the developer
used to minimise the upgrade work you have to put in.

I have not seen any arguments that make me think that libtool parallel
installs are a bad idea in principle.  Several good arguments as to
why the implementation I backed out of the release branch was flawed
notwithstanding.

Cheers,
        Gary.
-- 
Gary V. Vaughan      ())_.  address@hidden,gnu.org}
Research Scientist   ( '/   http://tkd.kicks-ass.net
GNU Hacker           / )=   http://www.gnu.org/software/libtool
Technical Author   `(_~)_   http://sources.redhat.com/autobook

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]