Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Sat, Jul 21, 2001 at 08:28:51PM -0300, Henrique de Moraes Holschuh wrote:
> On Sun, 22 Jul 2001, Marcus Brinkmann wrote:
> > 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.
>
> Well, I advocate adding the autotools-dev machinery to debian/rules clean
> for this reason. It will cause the new config.sub/guess to be propagated *to
> the source package*, so the GPL will not be violated. And the source will
> work out-of-the-package on the new archs, too.
I think there are error sceanrios. If you build the source, and then a new
autotools-dev will be uploaded and installed by the autobuilder, and then
the package is build on that. AFAICS, the build will update the scripts,
as the clean target is called by dpkg-buildpackage.
> > 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.
>
> Well, config.{sub,guess} is used by the configure script, not autoconf or
> automake themselves. If one properly touches the files before the build,
> they are not regenerated...
I was a bit sloppy and used autoconf/automake to refer to the whole
stuff, from the input files over the tools to the generated and installed
files liek config.sub etc.
There are differences, though, as you rightfully point out.
> > 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.
>
> Hmm... I see your point. But we are not changing anything but
> config.sub/guess, which are only a run-time (not build-time) dependency of
> autoconf and automake.
What I mean in our context is that the config.sub/config.guess files
should be copied before building the source. Sorry, I was really sloppy.
> > > 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.
> autotools-dev machinery in debian/rules clean will ship the new, fixed-up
> source.
See above, it won't if the autobuilder updates autotools-dev before
building the package (to a version newer than the one used when building
the source).
This does probably not happen for the currently up to date ports (or is
unlikely), but it happens for lagging ports frequently, and certainly
happens for new ports which compile the whole archive from scratch.
> > Concern: Information which version(s) works on some architecture is
> > obscured or lost.
> Can be worked around: the more complicated script I suggest will tag the
> changelog properly. That information is NOT lost, as it makes to the
> .changes file, which is sent to the proper @list.debian.org ML, even if the
> autobuilder is not doing a source NMU.
Again, does only work if the files stay fixed atfer the source is generated.
But, hey, if the files stay fixed after the source package is build, I have
absolutely no concern whatsoever. I am absolutely not against a convenient
way for maintainers to update the files in the source (by running
debian/rules autotools or whatever). I'm cool with that (it's great even!).
We just need a good way to make sure they are not overwritten when doing
a dpkg-buildpackage -B.
> > 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.
>
> Eh... you do know config.sub/guess are *run-time* dependencies of
> autoconf/automake-*PRODUCED* scripts/makefiles, don't you? They're not
> build-time (as in when generating the configure script and Makefiles -- not
> the build of the package itself) dependencies of autoconf/automake (unless
> you're buiding the autoconf package, I think).
>
> Autotools-dev has a lot to do with the configure script, and little to do
> with the running of autoconf, automake, libtoolize or something like that to
> regenerate said script.
I am confused. If it is the way you describe it, that the files are only
copied at source package build time, I am absolutely happy. What I have
problems with is copying them at binary package build time.
> > 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).
>
> A proper target for pre-build setup would be a good thing IMHO. I don't like
> using the clean target for that. Such a target should be used to call the
> autogen.sh scripts for when building from a CVS-exported tree, updating the
> build environment (calling autoconf, autoheader, automake, libtoolize,
> gettextize), and updating the build environment support stuff
> (autotools-dev).
Sounds like a good thing. This target would be called by dpkg-buildpackage
if it is packaging the source package, but not when building a binary
package only. Is this what you mean? I would be happy with that.
It also leaves it open if we want autobuilders to run this target
or not: We have the technical ability to do both, and can worry
about the way we use it just a teeny bit later (or do it differently
from package to package or port to port).
I would have absolutely no concern with that. In fact, I would like it.
> If you could write the policy proposal and post it to -policy, we can get
> proceed from there...
Well, we don't really need a policy for that to do it that way. As I see
it, the only change in your suggestion would be to remove the autotools
target from the clean targets dependencies. The maintainer would then have
to memorize to rerun this target before building the source. Maybe
some people can do it this way for some time, and then when we have some
existing practice, we can solidify it in policy.
> > Still, I don't want programs to call libtoolize -f in debian/rules.
>
> Well, the only way to do that properly is to get a new debian/rules target
> :(
I hadn't thought of this solution. It will not solve the problem of
out of date files in old source packages, but it would make it much better
because those files will be automatically updated more often.
Thanks,
Marcus
Reply to: