* Vincent Bernat <ber...@debian.org> schrieb: > >> Some users just don't have recent enough autotools to rebuild the > >> configure. > > > They should simply install it. Similar as they need recent toolchain, > > make, pkg-config, etc, etc. > > No, no, no. Users are not limited to Debian developers using Sid. Users > may try to compile on an old RHEL 2.
In this case they should really *know* what they're doing. RHEL is meant as an binary-only distribution - you should NOT install arbitrary packages without going through the whole distro's build engine and qm process, otherwise they'll risk merly all the stability ensured by the distro - that's a design aspect of those distros. On the other hand, there are often cases where you *NEED* to rebuild the whole configure stuff. > They should absolutely not try to rebuild configure since it is likely > to not work and leave them with an unconfigurable package. Why that, exactly ? > On most projects, there is not autogen/bootstrap in the realeases for > this very reason: do not confuse the user and let him install autotools > which is not mandatory at all. autogen/bootstrap > is shipped in the VCS repository because this is targeted at developer. Wait a minute! Arbitrary _users_ should never try to rebuild anything on a stable/production system. As soon as you're attempting that, you're stepping into the package maintainer or developer role, and then you should *know* what you're doing (or at least learn it). > autotools are aimed at the end user, not the distro packager. This is > stated in the introduction to autotools. This is nice to be nice with > the distro packager but the primary target is the lambda user (which is > usually less skilled than the distro packager). That's one of the fundamental conceptional flaws. > Compiling software from source is enough a pain to avoid any unecessary > dependency. Compiling software is task for developers or package maintainers. Users should use the finished packages provided by their distro. Again: we're talking about production systems here. > Oh sure, if there is a problem that can only be detected at runtime, I > will let the user deal with it in some "make test" that nobody runs That's why he should use distro's packages. > instead of handling the problem for him in most situations in > configure. That bit of convenience for the specific (and nowadays relatively rare) case that somebody just wants to compile and install some package from upstream source, for **EXACTLY** the same system it will be running on, overweights the hell of trouble for all the distro maintainers ? On a QM perspective, guessing something about the target system from the _running_ system is an absolute NO GO. The whole idea is inherently flawed. > Again, configure is targetted at the end user (which usually > does not cross-compile). It should automatically configure the software > to be in a workable state after compilation. And that's what it does NOT solve. AC_TRY_RUN+friends guess wrong, as soon as the building system is not equal to the actual target. > No need to read some README or run some additional scripts. Just design the software that it does the necessary checks at runtime, if there *really* is something that cannot be found out with toolchain- only based tests (which are NOT executing any code compiled for the target). > As upstream, I care about Debian and cross-compiling but I also should > care about people wanting to compile my software on old RHEL 2 or on > Debian Etch (an old enough platform to require some runtime test in my > case). None of those platforms have a recent enough autotools to rebuild > configure, BTW. Then they should be updated. cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100917070839.ga23...@nibiru.local
