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

Re: RFC: Rules for distro-friendly packages

Hi, Enrico:

On Friday 17 September 2010 09:08:39 Enrico Weigelt wrote:
> * 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.

Wrong.  RHEL is *a* Linux distribution.  A comoditization of well known 
practices in order to make sysadmin lifes easier (with its own share of 
idiosyncrasies) that pre-dates by long, long time those distributions and 
that, basically, have settled into the `./configure && make && make install` 

Think of the most probable environment where somebody goes with the hassle 
of "compiling new package into old RHEL 2".  Do you think such a chore is 
taken out of fun?  Or is it an environment where an overworked sysadmin at 
charge of a lot of disparaged machines is put into that need because out of 
his reach constrains?  RHEL is a fine environment; Debian is even better but 
forcing a busy sysadmin to intimately know about all the fine and gory 
details of Debian, Red Hat, Solaris, HP-Ux and AIX, just to name a few, not 
out of his own convenience and without the strongest need is not only a hard 
proposition but it is unrealistic.

> On the other hand, there are often cases where you *NEED* to rebuild
> the whole configure stuff.

Truly.  As there are cases when I have to go through the Makefile or even the 
source code to patch them so they run in my systems. But, please, do not make 
those cases more usual that *strictly* needed.

> > 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 ?

Because as much as any other software, autotools tend not to be forwards 
compatible: as long as you use a feature from x+7.y.z it will probably fail 
when runing older x.y.z.

> > 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.

Quite true.

> Wait a minute! Arbitrary _users_ should never try to rebuild anything
> on a stable/production system.

You seem to forget that in the context of this discussion "arbitrary users" 
are sysadmins on their duty.  They are perfectly expected to be recompiling 
software on stable/production systems.  Heck, it's even there, on the FHS:

'/usr/local': The /usr/local hierarchy is for use by the system administrator 
when installing software locally.
'/usr/src': Source code may be place placed in this subdirectory, only for 
reference purposes.

Pre-compiled software is a darely and these-days-very-common convenience that 
any sysadmin will take advantage of if at all possible but don't forget that 
*the* distribution format is the source tarball.

> 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).

Ah... those youngsters... package maintainers are a very convenient and most 
praised *proxies* for the work of the sysadmin.  Of course a sysadmin has to 
know his trade but, please, do not multiplicate idiosyncrasies for the sake 
of it nor make conveniences into obstacles when not strongly needed.  Of 
course "proper packages" are "better" but in many situations a make install 
onto /usr/local is good enough and "better" may change its meaning when 
dealing with half a dozen different unix-like systems.

> > 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.

It might be the case, but then it's a "fundamental conceptional flaw" from the 
very developers of the tool.  It's usually not too wise to go against the 
producer conceptions.

> > Compiling software from source is  enough a pain to avoid any unecessary
> > dependency.
> Compiling software is task for developers or package maintainers.

It's not.  Compiling software is a task for sysadmins too.

> Users should use the finished packages provided by their distro.

As long as possible.

> Again: we're talking about production systems here.

That probably means that the sysadmin will try the building process and 
functionality on a test system, not that he won't compile when need arises 
(and for any "real world" scenario it certainly arises).

> 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 ?

Don't forget what is the case for distro maintainers which is to help 
downstream users, not to make their lives even harder.

> > 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.

Yeah, well... that's not so constructive.  Well, programs should work 
flawlesly in any environment and developers should possess outnatural powers 
to advance every possible scenario where their programs might work.  There.

You can bet no sysadmin maintains and ages old system out of lazyness.  That 
those systems *should* be updated won't magically make that they *can* be 


Reply to: