Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Sat, Jul 21, 2001 at 07:24:12PM -0300, Henrique de Moraes Holschuh wrote:
> >
> > How bold. I am one of those against doing these things automatically,
>
> Heh. I feel bold right now. Might be this VT's fonts fault, though.
;)
Thanks for the summary of the points. It helped me a lot to get a clearer
idea why I feel uneasy about copying the files into the source tree.
> > feasible to do it that way, we could just do it externally to the package,
> > in the autobuilders for example. This would save almost everyone
>
> Well, the problem of doing that automatically *in the autobuilders* is that
> config.sub/guess files can be in strange places, or they might not be the
> GNU config stuff at all. I'd be wary of doing THAT much intrusive automatic
> updating.
I agree. There are reasons why doing it externally in the autobuilders
is worse than doing it explicitely in the package.
> > the effort. The reason not to do it either way are basically the same.
>
> I suppose so. It ends up being more a matter of personal taste than anything
> else. If you don't do it automatically, you either track GNU config changes
> on your own, or you will cause breakage in new archs sooner or later. If you
> do it automatically, GNU config upstream might screw up, I might not notice
> it in time and let it leak to autotools-dev, and cause breakage in your
> package.
I am always concerned about external dependencies in package sources. Not for
the reason you mention above, that what you rely on might be broken. As you
say correctly, this can always be the case (our software has bugs). But
because information might get lost or is obscured, information concerning
the dependencies of the source on the external world. One example is
debhelper. At the doc -> share/doc transitions, sometimes things were
messed up because debhelper installed the docs in a different place the
source package expected it. In this case, the dependency was not hard enough
to make sure that the package compiles. The same might happen with the
autobuilders and autotools-dev: Although autobuilders have now a good
way to make sure that the packages will build, there is no well defined
place where this information is available to the user.
Users might be surprised why the package fails to build
although the build dependencies are fulfilled.
Then, I have doubts if the GPL requirements
are met, as the source used to compile the
package (and config.guess/config.sub are part of that source) is not
available through the user under the conditions set forth in part 3. of the
GPL.
> > It also completely removes the benefit of the builder not needing the build
> > dependency on the relevant packages. For this benefit, the upstream authors
> > of these tools go along way in compatible shell programming.
>
> I didn't really understand the above paragraph. Could you rephrase it,
> please?
Well, the idea of the autoconf/automake suite is that you don't need to install autoconf etc to build the software. They go a long way to make sure that
an installation is not necessary prior to building the package.
I think Debian should support this by always making sure the autoconf/automake
generated files are regenerated when the files are changed before the source
package is built.
> > If either point has been "beaten back", I'd like to see a more specific
> > pointer than lists.debian.org.
>
> Well, some complained that upstream changes (to GNU config) could break
> semantics: beaten back becuse GNU config interface is frozen in
> always-backward-compatible by design.
Agreed.
> Others complained the build system would be different from the autobuilders'
> system: duh. If it were not different, you would not need GNU config; A
> package will build differently in an BE machine and a LE machine even if
> they have the same config.guess/sub files.
Concern: GPL requirement to ship the whole source.
Concern: Information which version(s) works on some architecture is
obscured or lost.
I don't agree with your comparison with BE/LE, because first, the compiler
suite is not part of the source code at all, and second, the difference
in LE/BE is completely predictable and does not depend on changes in the
source, but is completely external to the program.
I think it boils down that autoconf/automake are designed to produce
parts of the source of the program, which is then used. They are written
to be used in the preperation of shipping the program, not as a tool used
at build time. I would be on your side entirely if autoconf/automake would
be more like flex/bison, or other external programs run in the progress of
building the program from the source.
That's why I would like the distinction between source code, build tools
and final program to carry on in the Debian source. Moving parts of the
source code to the build tool area doesn't seem to be appropriate to me.
Especially if I am correct with the observation that the GPL doesn't allow that (note: I did only do a quick review of the license on config.guess.
Maybe this is an issue for debian-legal).
> Others complained that brokeness in autotools-dev could cause silent
> breakage.
> Well, it can. But it is no worse than any other bug in gcc or
> libtool, or binutils.
Agreed.
> And I am *really* careful when I upload a new
> autotools-dev: I *always* go over all upstream changes line-per-line -- if
> one is going to upgrade GNU config, either automatically or manually, one
> might as well take advantage of that and use whatever is in autotools-dev ;)
I see the benefit, and believe me, I suffer from out of date sources just
like any other port. I filed dozens of bug reports against out of date
libtool versions. It has given me a lot of headaches, because the breakage
is silently and heavy (missing dependencies, error when linking with the libs).
Still, I don't want programs to call libtoolize -f in debian/rules.
Thanks,
Marcus
Reply to: