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`
paradigm.
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
updated.
Cheers.
Reply to: