Re: automake/autoconf in build-dependencies
Henrique de Moraes Holschuh <hmh@debian.org> writes:
>> When I include the configure script in my source packages, I can feel
>> pretty confident that they package I upload will stay buildable even
>> if a week from now autoconf or automake gets updated to something not
>> backwards compatible.
>
> Yes. That's how I see it as well.
As I understand your suggestions in autotools-dev:
Machine generated files (e.g. configure) constructed by autotools
should not be in CVS.
However, these files (as generated by the Debian maintainer's autotools
run before the upload) should be included in the source package via the
.diff.gz. so that the user doesn't need autotools.
Therefore, the Debian maintainer should run autotools using current
config.{sub,guess} before the diff.gz file is generated, possibly via
an 'autogen.sh' script.
The README.Debian.gz from autotools-dev states:
===
"One can either get this script [i.e. autogen.sh] to be run by
configuring CVS to do so, or by adding some Makefile rules in
debian/rules.
Do note that a properly done autogen.sh invocation runs before dpkg
has a chance to build the source package, so as to make sure an user
does NOT need any of the programs called by autogen.sh to build the
package. This will, in fact, ease the load on auto-builders as well
since the program will build much faster."
===
1. How does one configure CVS to run the autogen.sh?
2. If the autogen.sh invocation is done during the build by
debian/rules it can't be done prior to "building the source
package", which I interpret to mean creating the .diff.gz. "Get
this script to be run" implies a dependency of some kind: a missing
configure script or a missing configure-stamp. And in that case,
the buildds will also invoke it.
3. When using cvs-buildpackage, a clean copy of the repository is
exported, but then dpkg-buildpackage kicks off without a chance for
maintainer intervention to do something before the build. Perhaps
I could use the -H<hook_script> option to run autogen.sh?
>> > - The extra space in the diff.gz expands the size needed on every
>> > single Debian mirror, as opposed to the short one-time penalties on a
>> > few buildd's.
>
> Unfortunatelly, it is still a good tradeoff. I am not even bothering about
> CPU time in the buildds anymore, since I got told by buildd admins and
> porters a number of times not to. BUT the long-term package quality
> benefits are worth the increase in space.
If the Debian maintainer has run autotools before uploading, should
the buildds re-run the autotools or not?
>> That's a real issue, but I still think the least bad solution is to
>> ship finished, known-to-work build scripts in the source package.
>
> Agreed. That's the current best practice for Debian, as far as I am
> concerned.
>
> In fact, best practice for Debian also requires that you use
> config.sub and config.guess from autotools-dev if your configure
> script needs them. Just a shameless plug for autotools-dev :-)
README.Debian.gz is a little obscure in places, and answers to the
above questions would be helpful to me.
--
Thanks, KBK
Reply to: