On Fri, Aug 06, 1999 at 02:40:06PM +0200, Stephane Bortzmeyer wrote: >>> - the rationale for choosing such or such options in the debian/rules when >>> calling configure and/or make. >> Why shouldn't this simply be in the debian/rules file where it's convenient, > Hmmm, because debian/rules is read by people who want to recompile (possibly > with different options) and README.debian by ordinary system administrators, > who just want to know? Remember that debian/rules is not in the binary > package.
Oh. I just didn't see any reason why a sysadmin would particularly care unless they were about to recompile it. I guess I just don't see what relevance compile options have without the code that they're compiling. At least in the common case. > > There's an existing proposal to have proper build dependencies, so this > > is hopefully redundant. > I don't think we should write the Policy by taking into account > changes which will be integrated in the next twenty years. Seeing > the buglist of dpkg, I seriously doubt that source dependencies will > be implemented soon. While a change in the Policy's "Documentation" > section is much lighter. I haven't been following too closely, but it looked like they were about ready to go, modulo some minor disagreements (with code and all). But yeah, if they're not, this isn't a bad alternative. (although having your rules file check for it and die with an informative error message seems more convenient. *shrug*) Cheers, aj -- Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. PGP encrypted mail preferred. ``The thing is: trying to be too generic is EVIL. It's stupid, it results in slower code, and it results in more bugs.'' -- Linus Torvalds
pgpAEs8gihwMT.pgp
Description: PGP signature
