Re: automake/autoconf in build-dependencies
Scripsit Daniel Schepler <schepler@math.berkeley.edu>
> - Putting autoconf-generated files in the source package is nearly as
> fragile as generating them at build time. If there are changes in
> autoconf which break the configure.ac etc, then the next time you want
> to make other changes or bring your changes forward to a new upstream
> version, you'll have to fix things anyway. This to my mind pretty
> much reduces the "future buildability" benefits to nearly nothing.
That's a reason *contra* in my opinion.
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.
The next time I upload I am going to either reuse the working
configure script from the previous package (if I'm managing things by
hand) or try to generate a new one with the tools I have available by
then (if I'm using cvs-buildpackage or one of its equivalents). In
the latter case, if anything stops working I will _find out_ before I
upload, both because I have to run the script myself as part of
building and because as a matter of course I run debdiff to compare
with the latest version before I upload.
However, if I left it to the source package to run autoconf by itself
weach time it is build, it could slide into unbuildability _without me
or anybody else noticing_ before it is too late and we have
not-buildable-anymore code sitting around in the archive, and most
likely even in testing.
> - 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.
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.
--
Henning Makholm "Larry wants to replicate all the time ... ah, no,
all I meant was that he likes to have a bang everywhere."
Reply to: