Colin Walters wrote:
> > But as soon as I need to modify any of the
> > template files (configure.ac, Makefile.am, etc),
>
> Fundamentally, if you're doing this, you're hacking the upstream source,
> and that likely means your changes should really be going upstream. If
> you're needing to change paths or something in the Makefile.am, that
> signifies that it should be a ./configure option, for example.
Some of the changes I've had to make are fairly debian-specific.
Building rpm with all libs shared, or making aalib-config not pull in
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.
> My personal approach is to never Build-Depend on the autotools, and make
> my upstreams use AM_MAINTAINER_MODE. Then, when I want to patch the
> upstream Makefile.am, I copy the old one to Makefile.am.old, and the
> current Makefile.in to Makefile.in.old, hack the .am, run automake, then
> get diffs between both the .am{.old,} and .in{.old,}, and stick those in
> debian/patches. By using AM_MAINTAINER_MODE I'm assured that patching
> these files won't cause timestamp issues.
This will often yeild big patches (on the order on 140k compressed, for
some of my packages) as you noted later on, 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.
I also don't think it would live well with revision control.
> > I may be moving towards always doing this, even if I don't currently
> > touch any template files.
>
> 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 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. 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.
> > Given the rapid pace of change of
> > automake, I can see this easily not happening, if I have a package
> > that only works with automake n, and version n is dropped from debian.
> > The user would then be stuck trying to update it to the current
> > automake.
>
> Now that different versions of automake are parallel-installable (except
> the bastard child 1.5), I think we'll be able to keep all of them around
> for as long as they're useful.
How do we know when they stop being useful? It's not as you can use
build deps to track this for most packages.
> > Instead, the right way to do things is to run it through the
> > preprocessor every time, and deal with it when it breaks. At least
> > you'll know then when it's broken so you can fix it.
>
> Yes; but on the other hand some of the breakage could just be spurious.
> So it just wastes your time.
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.
--
see shy jo
Attachment:
pgpW8PLTrla4l.pgp
Description: PGP signature