On Sun, 8 May 2011 22:36:20 +0200 Enrico Weigelt <weigelt@metux.de> wrote: > > The options are just passed on unchanged. No problem with that. Can > > still call ./configure directly. Maybe it wastes a little bit of time > > but if you're cross-building, you're using a really fast machine so > > this is hardly of concern. > > Requires that you can really pass all required options *and* > environment variables reliably. I've seen packages where this > wasn't the case. Just as there are packages which cannot be automatically built just from the VCS checkout and ./autogen.sh, hence the need for tarballs where that work has already been done. I think you've argued yourself into a corner there. > > and all the other build systems out there are suddenly compatible > > across all packages?? Dream on. > > At least, for autoconf packages, which follow the rules I've written > down here: > > http://www.metux.de/index.php/de/component/content/article/1-software-entwicklung/57-rules-for-distro-friendly-packages.html > > that would be the case. Those aren't rules, those are your preferences which you wrote yourself. I reviewed them when you first posted about them and I discounted the majority as a combination of over-elevated preference and complete dreamland. I'm not going to have time to continue feeding your trolling. I've said my bit, nothing you've said has been a new argument for the elevation of your pet system to be deemed "best practice" by anyone except you. Try that with any of my upstream packages and I'll laugh at you, then ignore you and then I'll add you to the killfile. Please stop this one-man campaign. It's already sounding tired and repetitive. > Actually, once I fixed packages to this, the individual distro > builder pkg configuration is reduced to nothing more than the > package name, list of available features and their enable/disable > flags, and the individual target config for the package just > tells the version and selected features. That's it. > > (see attached files) Gentoo have been trying that for quite some time but it still needs a wide range of specialist tools to keep it working. > > That's not technical and there is no one organisation which bridges > > all of the various upstream teams. If you want to change things, you > > must persuade each team to adopt your preferences and you have > > That's not necessary. Having a project, where people like distro > package maintainers come together (at least for a bunch of packages > and growing it later) and maintain stabelized and distro-friendly > downstream branches. (oh, that's what OSS-QM is meant for ;-o) Then I'm glad I've got nothing to do with OSS-QM and I have no intention of modifying any of my upstream packages to meet your personal preferences, even if you continue to dress them up as requirements. > > > Exactly the same reason why things like AC plugs, voltages and > > > frequencies are standardized. > > > > Not true. Those things MUST work together in every permutation within a > > specific jurisdiction or people can die. Debian and autotools are > > nowhere near that level of importance. > > Probably not. But why not learning from the other areas of engineering ? The benefit has to be transferable across fields - blatantly the analogy you drew has no relevance to autotools. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgppel7wl55WI.pgp
Description: PGP signature