Re: Chapter 13 again ...
On Tue, 18 Jul 2000, Theodore Y. Ts'o wrote:
> Date: Tue, 18 Jul 2000 08:21:58 -0400
> From: Theodore Y. Ts'o <tytso@MIT.EDU>
> To: Shaya Potter <spotter@yucs.org>
> Cc: wol@thewolery.demon.co.uk, lsb-discuss@lists.linuxbase.org
> Subject: Re: Chapter 13 again ...
> Resent-Date: Tue, 18 Jul 2000 14:22:17 +0200
> Resent-From: lsb-discuss@lists.linuxbase.org
>
> 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)
I am not a slackware advocate, but i use slackware for work (as red hat
for desktops, bebian for servers and so), and i would like to
remark that rpm is included with slackware distribution since version 4.0.
It works as any other rpm, and installs everything correctly, just use
--nodeps if you have some troubles.
obviously slackware native packets still are .tgz, but that is not so bad.
So you do not need alien to install rpm on slackware, you
have rpm package manager installed (obviously if you decided to install
it at the beginning).
>
> 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 have a BSD style boot system.
anyway under /etc/rc.d you do have some scripts,
they are bsd style scripts.
But anyway a sysV scrips located in /etc/rc.d will be executed correctly
at boot time, and it will work normally.
This feature has been introduced since version 7.0, and it works,
i experimented it
without any problems.
> 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?
Three years ago i wrote the scripts system a la sysV to use them on
slackware,
instead of the bsd boot style scripts.
It was includind chkconfig and /etc/init.d directory, and so on.
the first model was for me Irix, then i worked and now this
strange slackware init system is LSB compliant. I sended a tgz packet
to wolkerding, if he wanted to include it
inthe contrib, so users could decide to switch to a sysV model
for their boot. but i got no answer.
i still keep this package.
if someone from slackware is interested, then please contact me,
i would be so happy to see it in the contrib directory.
it has been tested on almost 10 systems, and no troubles at all.
and it is very clean, also if not so clean as a BSD style boot.
but for a sysV is very clean.
>
> 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.
>
Alien converts rpm, deb, slp, tgz packets and no trouble.
> 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
>
>
> --
> To UNSUBSCRIBE, email to lsb-discuss-request@lists.linuxbase.org
> with subject of "unsubscribe". Trouble? Email listmaster@lists.linuxbase.org
>
Luigi Genoni
Reply to: