Re: automake/autoconf in build-dependencies
On Sun, 13 Mar 2005, Henning Makholm wrote:
> 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.
Experience tells me you are wrong.
> 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.
> > - 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.
> 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 :-)
--
"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
Reply to: