Re: automake/autoconf/libtool -- convince me
On Tue, 2003-06-10 at 21:29, Joey Hess wrote:
> Some of the changes I've had to make are fairly debian-specific.
> Building rpm with all libs shared,
Seems to me that upstream should have a --enable-all-shared or
something.
> or making aalib-config not pull in
> gpm,
--disable-gpm ?
> so it can work on hurd. I'm sure I could pass a lot of this
> upstream, and in the main I do -- I've passed tons of aalib and rpm
> fixes upstream. Problem is you always end up in the situation where
> something just broke, and you have to fix it now, not when upstream gets
> around to it.
Sure; as a temporary situation it might be reasonable to Build-Depend on
the autotools. But in the long term I don't think it's right.
> This will often yeild big patches (on the order on 140k compressed, for
> some of my packages) as you noted later on,
Only again if upstream's automake is much older. If that's the case
anyways you probably want them to be updating it.
> and it's a little bit too
> grubby for me. It's only one step from having patches to automatically
> generated files lying around to editing them. I've seen it happen.
Yep. It's an unpleasant temporary situation until the stuff goes
upstream.
> I also don't think it would live well with revision control.
Dunno, just make the patches binary.
> > Now *this* is evil. You're going to be making your builds a lot less
> > predictable and reliable for no good reason.
>
> I'm thinking about doing it just because I want this:
I think that's bad, for reasons described earlier and below.
> > > - I want my packages to be as useful as possible to users. This includes
> > > letting users modify the template files if they need to and build the
> > > package, and have the build succeed.
> >
> > I dunno. I personally would never use the Debian packages of something
> > as a starting point for hacking the upstream source. People shouldn't
> > expect it to work in general.
>
> Hmm, it depends what level you're hacking on. If you want to give a
> kernel patch to linus, you should work from the linux kernel. If you
> want to build the debian kernel with a tweak or two, you should use the
> debian kernel source.
That's entirely different, because linux doesn't the use autotools.
> We have many users who compile packages with
> different configure flags, and it's just a short hop from there to
> needing to fix some issue in the configure.ac.
I very much disagree with "short hop". If they need to be hacking the
configure.ac, they'll probably need to be hacking other things too in
the upstream source, and who knows what other kinds of tools they'll
need, like docbook, gob, etc.
Your job as a Debian packager should primarily be to make the Debian
package build well. I think the real bug in your scenario is that we
don't have a standardized infrastructure for adding configure flags.
This is something that is being addressed by cdbs.
> How do we know when they stop being useful? It's not as you can use
> build deps to track this for most packages.
We'll just keep them around for say a decade or two. Given the rate of
growth of the Debian archive relative to the number of incompatible
upstream automake releases and their sizes, I think the extra space will
be like much less than statistical noise.
> Sure, but in practice, only rpm has wasted my time, and its use of
> autotools is gross, and needs extensive hacking for debian. It hasn't
> been much of a problem so far for other packages.
Ok, it sounds to me like rpm is a fairly special case, and I'm certainly
not going to fault you for not going the extra hundred tedious miles and
making all your changes into clean upstream patches. But as a general
solution, I think Build-Depending on autoconf/automake/libtool is bad.
Reply to: