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.
> 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...
Someone build-depending on autoconf/automake is probably not trying enough
to lessen the load on the autobuilders. This has, however, nothing to do
with config.sub/guess or autotools-dev.
> 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.
> > 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.
> 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.
> 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.
Well, BE/LE is the lesser problem. Interger sizes, and other weird stuff can
also change from one arch to another, I think. I'm only point out that
changing config.sub/guess will not make the mess any worse.
> 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.
> 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).
If you could write the policy proposal and post it to -policy, we can get
proceed from there...
> 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
:(
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Attachment:
pgpf_KhacG4sE.pgp
Description: PGP signature