Re: Package System specification
"Theodore Y. Ts'o" wrote:
> From: Jochem Huhmann <firstname.lastname@example.org>
> Date: 15 Apr 2000 01:01:31 +0200
> Yes. What is "RPM"? It is a tool, but a tool that only works as expected
> if the dependencies work. SuSE and Redhat and whatnot are using RPM. So
> can you just install rpms for SuSE on Redhat or vice versa? No, you
> can't. The package format is irrelevant, it is a very tiny problem. If
> there are no common dependency trees, a common package format doesn't
> help much. If there is a common tree, you can savely convert from one
> format to the other.
> This is a known problem, and we've discussed this already. It means
> that when we specify an LSB RPM, it can only use dependencies which are
> defined by the LSB (which will probably be prefixed by lsb-*, or some
> such). It is expected that distributions will have to load some kind of
> "LSB compliance" package which will make the proper LSB definitions
> expeced by the LSB, and create the appropriate LSB filter libraries, as
I suspect this is the right way to do this:
lsb-1.0-<rev>.<arch>.rpm contains the filter libraries and depends on
the underlying distribution-specific libraries.
Resulting applications then can depend on "lsb version == 1.0" or "lsb
version >= 1.0", and of course on each other.
The lsb dependency thus becomes a choke point in the graph; anything
below it is distribution dependent, anything above it is application
dependent. If it crosses the line without going through the choke
point, the application is noncompliant. One of the beautiful things
about this is that it can be verified automatically!
This, of course, should be in the spec.
As far as package formats, I always thought it would make sense to have
.tar.zip or .cpio.zip be the package format -- it could be extracted
with gzip just like a .gz file (and you get the first member, which
should be the tarball), but it can also contain additional, separately
compressed member files, which could be used for metadata.
RPM doesn't do that, but I'm happier to have fewer formats than a
proliferation of "better" formats. Really.