Re: Removal of libtool1.4
Scripsit Scott James Remnant <scott@netsplit.com>
> On Mon, 2004-01-19 at 12:16, Henning Makholm wrote:
> > Remark that the first change may well be limited to
> > touch configure.in
> > If that makes things break (and, because of libtool1.4 being gone, it
> > is not possible to prevent the breakage by having the right packages
> > installed), then I don't see how it can *not* be a bug.
> Add AM_MAINTAINER_MODE to configure.in, run autoconf.
You are missing the point. The point is that aclocal.m4 is a
*generated file*. It is *not source*. That means that we should
distribute the tools necessary to *regenerate* it from source.
Or, at least, we should distribute newer tools that can be used to
build a working package from source, even though the generated
intermediate files may not be exactly the same as the one found in the
source packages.
> You'll then *never* need to run aclocal again,
Except if one follows the advice from autotools-dev of not to keep
aclocal.m4 under version control but regenerate it each time one does
a fresh checkout. I think it is good advice. I may be wrong, but in
that case we need to reach a consensus that best practise is to keep
pristine upstream aclocal.m4's around, instead of beginning to throw
out stuff on the expectation that practises will change to accommodate
the throwing-out after it is done.
Also, except if one wants to change things. Debian is fairly
narrow-minded about allowing users to change things. I believe that is
a good policy. But our efforts to make sure that users have the
*legal* power to change things go down the drain if we withhold from
our users the *technical* means to change things.
>From a legal standpoint, if one of the packages the problem applies to
is GPL'ed, removing libtool1.4 will make it illegal for us to
distribute binaries for that package. Quoth the GPL:
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
If we refuse to distribute the scripts necessary for turning the
"preferred form for making modifications" - which includes
configure.in (created by a human programmer) but not aclocal.m4
(generated by a script) - into a binary we distribute, then by the
GPL's definition we do not distribute the complete source code, and
then we are in violation of the GPL.
If we make sure that all the packages in question *can* in fact be
built from real source (as opposed to our pre-digested "source
packages) with a toolset that does not include libtool1.4, then we are
in the clear for ditching it. But such making sure requires more than
wishful thinking and hand-waving.
In my previous posts, I've narrowed down the set of possibly
problematic packages down as far as I can currently think of ways to
do by automatic means. It is not inconceivable that some or even all
of the packages I found indeed work well with autoconf 2.5x and
libtool 1.5+, but we need to establish this *positively* before
throwing out the old libtool package.
--
Henning Makholm "The practical reason for continuing our
system is the same as the practical reason
for continuing anything: It works satisfactorily."
Reply to: