Eddy Petrişor wrote: >> ? I didn't say to do that. Patching the Makefiles used by autotools >> before cdbs runs was my point. > > Err, yes, my bad, indeed, you did not say that.
OK, I see the problem. I've used "autotools" where I really meant "automake" - i.e. the normal make process that all binary packages need to be built from the upstream source tarball. ./configure, make, make install. That was my bad - I'm upstream as well as maintainer for all my current packages and it's easy to forget where one stops and the next starts for other maintainers who are not also upstream. Sorry for the confusion. >> OK, so maybe that method requires at least some upstream assistance - >> but I wasn't actually advocating running autotools in debian/rules. My >> point is that by tweaking the Makefiles and associated build scripts >> with patches, there would be no need for changes in debian/rules at all. > > I sincerely doubt any sane upstream would incorporate changes to make > their source compile in two different configurations of the same > software just to please Debian. Maybe, but I (as upstream) have incorporated changes upstream to support two different architectures of the same source before. I found that MacOSX/Fink requires frequent autotools tweaks upstream and there are other tweaks for Solaris, etc., etc. This change - as I read the original question - is more of an architectural thing than a tweak only to suit Debian. It could well help other maintainers like Fedora or SuSE who also have to build for specific architectures. >> autotools are run (once) via the normal cdbs processes as before, but > > Err, didn't you say that you were not advocating running autotools > from debian/rules? Or am I missing something? Yes, but it wasn't really what I meant. Sorry. :-( I meant ./configure make make install, nothing more. Patch the upstream source (using cdbs), run the rest of cdbs as normal. > As I said, I doubt any sane upstream would incorporate rules to build > their software configured differently just to please Debian. I, for > one, would not welcome our new autotools-fiddling-for-debian changes > :-) . It depends, I try to keep in touch with a Fedora maintainer for my own packages and his experiences help me create an upstream tarball that suits both Debian and Fedora - in the hope that it will also be easier to use on other systems. In my upstream work, I'm not aware of any objections to making the released code easier to build on a wider range of systems. All these conditional build settings can be made into ./configure options and then it's easy to request cdbs to use or not use specific options. There's no need for this change to force everyone else to build 2 binaries, just adding support for those who do need 2. This example could be made "--enable-libfoo386" with a default to no. If this is expressed as an architectural thing rather than Debian-only, upstream may well be willing to at least help out. Asking for "--enable-libfoo-deb" is not the idea. Upstream will (and should) tend to see Debian-only problems as "not our fault" but - to me at least - the original question was an architectural issue that could apply to other distributions. That can be a key factor in how the request is phrased to upstream. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
