Re: RFC: Rules for distro-friendly packages
* Vincent Bernat <bernat@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: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
Reply to: