Re: Removal of libtool1.4
* Henning Makholm <henning@makholm.net> [040119 22:51]:
> 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.
It may be generated, but is good source nevertheless. Consider
a similar case: I'm writing some program that uses some code
from same large package, say kernel, xfree or openoffice.org,
by copying some pieces of code from there in my program.
I guess we still agree, that I do not have to put the whole
kernel, xfree or openoffice.org sourcecode in my source.
Now consider the case I add script, that can sync those files
by graping the .c's from the large package's source and copies
them in positions where I keep the files in my source tree.
Do you really want to say I would have to ship the whole
kernel, xfree and openoffice.org sources with my little package?
Or let us try it another way: Source is the prefered form for
modification. Now let us look what I do when I don't like what
one of the macros does and want to change it. I surely won't
normaly load the source of the package where the macro is from,
change it there and install the .deb. I also won't fiddle arount
file in /usr directly. I will copy the part of aclocal.m4 (because
there I really know it is, I won't search long where the file it is
copied from resides) into some local .ac file, change it there and
call aclocal with -I . ,if I want to sync the rest anyway, or just
append it also to aclocal.m4.
The only reason why having all the macros around is nice is so that
syncing (i.e. regenerating) the macros is easy, which also is the
easiest way, to add *additional* source to the package, if one wants
to have addional features in configure.in. But I really doubt source
can be extended to "All files an other programmer might want to add
in some future because of changes.".
> > 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.
This is good advice for some maintainer of the code. It's nice to always
recollect the code, to be up-to-date. But we are speaking of some
released bunch of code, placed in a debian source package. Noone stops
you from having a fresh aclocal.m4, you only have to adopt your scripts
so that they can work with the current version. (And if you want
non-current versions, the advantage of regenerating them is really
mood.)
> 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.
I'd support that, but my conclusion is to use AM_MAINTAINER_MODE
and things like that everywhere, so that no automake, autoconf and
things like that fiddle with my changes I do, unless I tell so.
> 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.
Well, I hope I already told before in this mail, why I believe this
has no point at all.
> 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.
What shall "real source" be? Hell, I even remember pristine sources that
could not even be build with gcc without changes. Does this mean I
have to place the whole other compiler in it?
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: