[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

 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: