Dmitry Borodaenko wrote: > First of all, thanks for bringing this up, Joey! This is a problem and > we should address it. Did you mean to send this to -devel? I assume so, so I am replying to there with some context. > On Tue, Jun 10, 2003 at 02:09:24PM -0400, Joey Hess wrote: > JH> How I handle automake and autoconf now is I try to avoid touching > JH> the unholy mess at all if I can. But as soon as I need to modify > JH> any of the template files (configure.ac, Makefile.am, etc), I > JH> switch the package over to build-depend on the tools, run them at > JH> build time, and clean up all generated files at clean time. I may > JH> be moving toward always doing this, even if I don't currently touch > JH> any template files. > > A case to the point: I can't build Mutt with NNTP patch from Vsevolod > Volkov (http://mutt.org.ua/), because Debian Mutt has patches that > modify Makefile.in, while Vsevolod's patch modifies Makefile.am. <gag> That's ugly beyond belief. It seems to me that Colin's approach of modifying the Makefile.am and then generating a new Makefile.in and a patch from that will kind of work in this situation. The user would probably have to figure out how to tell DBS, or whatever patch manager he uses not to apply the Makefile.in patch, and then they'd be back to hoping that the rarely-tested automake works. Of course this situation is handled fine by my approach, with no hacking. Just patch the Makefile.am and build and away it goes. > Look at how Colin's major points apply to this situation. > > 1. Go upstream for major changes. > > NNTP patch is very large piece of functionality that _needs_ to hack > upstream source, and in the same time there is no sense in going > upstream: upstream Mutt is not yet ready to accept changes of that > magnitude into itself, and that is why Marco rightfully refuses to > include this patch into the official Debian Mutt package, too. Yet, I > need this functionality now, and together with latest Debian Mutt. > > 2. Start hacking from upstream source, not from Debian package. > > First of all, I want a Debian package, not some /usr/local installation, > and on top of that, Debian Mutt package includes a lot of nice things > (not to mention security hot-fixes) that end up in the upstream > eventually, but not soon enough. > > 3. Primarily, make the Debian package build well. > > That is not the first priority: for end-user, it should work well; for > developer, it should not only build well, but also patch well. Patching > a package that modifies generated files sucks: try to build a Debian > Mutt with NNTP, if you don't believe that. > > 4. We're stuck with autotools as they are, portability breaks, etc. > > If we have a problem with the toolchain, we will never get it solved by > walking around it, we can only fix it if we do it properly, and solve > all the problems that this ensues. We don't have a marketing breathing > down our necks, and isn't Debian supposed to be The Best OS? > > -- > Dmitry Borodaenko -- see shy jo
Attachment:
pgpk8p4HPKhDg.pgp
Description: PGP signature