Re: Chapter 13 again ...
Date: Tue, 18 Jul 2000 02:38:30 -0400 (EDT)
From: Shaya Potter <spotter@yucs.org>
> Sigh, OK. So let's go over this, one more time.....
>
> 1) The reality is that RPM is the de-facto standard. Just about all
> modern distributions support RPM files; even Debian can read RPM
> files, using the Alien package. (Slackware doesn't, but it's so
> backwards in so many other areas that it wouldn't be LSB compliant
> for all sorts of other reasons; in fact, some would claim that it
> hardly qualifies as a "modern distribution.")
Ted, I'm no slackware lover, but you don't have to get into attacking
slackware. Some people like it, and that's good enough. In reality,
Alien works on slackware just like Alien works on Red Hat and Debian. It
lets you install a foriegn package with the package manager that is native
to that distribution. One might argue on the merit of slackware's native
"package manager", but slackware users could just as easily install LSB
packages as Debian users could (or Red Hat users could install DEBs if
they had Alien installed)
Slackware doesn't obey the filesystem standards (no /etc/rc.d scripts of
any kind, for example), so it's unlikely that a LSB-compliant
application --- which is allowed to expect things like this from a
LSB-compliant distribution --- will work on Slackware anyway.
(There's a separate part of the LSB specification that deals with the
location of the init.d scripts plus the issues of rc.d script ordering.
Basically, we abstract that out. But you need have *some* kind of
rc.script system, or things aren't going to work.....)
Slackware could fix this, and they other issues that take them away from
being LSB compliant ---- perhaps they will, assuming that we actually
can push LSB out the door and ISV's start adopting it. Who knows?
It is good to know that alien work with Slackware ---- although I'm
surprised. I thought alien worked by actually transforming an RPM
package file to a dpkg package, and then using dpkg to install the dpkg
file. I didn't think alien was flexible enough to be an arbtriary
package translator, that also handled slackware "packages".
True, but one most also remember that imposing the RPM utility on others
is also a bad idea. The LSB should (IMHO) maybe rely on the RPM format,
but use a more general interface, so that one might easily wrap it around
rpm, or around a alien/dpkg or alien/slackware'ish installation.
This is exactly what we're doing. See Dan Quinlan's earlier message for
his proposed command-line utility for the LSB package tool (which would
be a RPM or dpkg wrapper script).
I don't know what "trigger scripts" are in the RPM world, I assume you
mean that a package can only use "post install" scripts (such as updating
inetd, cron, rc.d structure.....) that the LSB defines to be LSB
compatible.
Trigger scripts are scripts in RPM-land that can run at arbitrary times
---- when another (arbitrary) package is installed or removed, as a
backdoor mechanism to deal bugs arising from the fact that RPM's
install/uninstall script ordering is best described as screwy. (There's
a complicated rationale behind it, but given that RedHat employees
making RedHat packages have been known to screw things up, forcing
people to use triggers to fix buggy postinstall scripts in the RPM
database, I consider it simply too complicated, and basically an
attractive nuisance).
Oh yes, because of the bizarre script ordering rules in RPM's, which I'm
Alien can't possibly handle correctly, because dpkg's runs the scripts
in the order which people are much more likely to expect, one of the
things that we have to have the LSB tool do is to implement the
"upgrade" functionality as:
rpm -e package
rpm -i package_file
It *must* not be done as follows:
rpm -U package
The reasoning behind this is that the ordering of the uninstall and
install scripts are very different between these two scenarios. In the
RPM -U case, the install script is run, and then the uninstall script is
run. This means that if the install script has code to add a symlink,
and, and the uninstall script has code to remove the symlink (for
example), the Wrong Thing will happen unless you use special shell
constructs. The problem with the special shell constructs is (a) they
probably won't translate correctly using Alien, and (b) when even Red
Hat employees can't remember to use the special shell constructs, it's a
sign that the system is fragile and Too Easy To Get Wrong. I did an
examination of RedHat 6.1 a while back, and every single Postinstall
script fit into one of three categories:
* Was wrapped using the shell construct.
* Should have been wrapped using the shell construct, but didn't
causing a bug (I found half a dozen such packages)
* Should have been wrapped using the shell construct, but since
the command was idempotent (i.e., ldconfig) it simply
just made upgrading less efficient because ldconfig got
executed multiple times.
(There is an excuse for this, which is that it allows for multiple
packages with the same name but the different version --- *if* they
don't conflict in terms of where they want to put files --- to be
installed at the same time. Unfortunately, with the exception of the
kernel, this basically never happens in real life, and the fact that Red
Hat packagers have to deal with this complexity for all packages, even
though they can't take advantage of this generality most of the time, is
a defect as far as I'm concerned. I've tried arguing this with the Red
Hat folks, but they won't listen. Oh, well. I use Red Hat on many of
my machines, but doesn't mean I blindly love everything about Red Hat or
RPM.)
- Ted
Reply to: