Re: non-dpkg packaging systems (was: Re: `pms' from BOGUS (Debian vs. BOGUS) )
> > The tool `pms' [Package Management System] is the heart of the
> > distribution; `pms' is driven by so called Notes files (think of it as
> > of `make' and Makefiles). A Notes file has three parts: [...]
> > [...]
> > To remember you: I don't want to argue which dist is better; my
> > intention is to consider how is it possible to improve Debian GNU/Linux!
>
> There's also RPM -- "Redhat Package Manager". I don't know its
> copyright status.
It's GPLed.
> I've never used it (I have a RedHat CD on order out of curiosity),
> but I have a copy of a "RPM HOWTO" paper which talks about it.
> >From what I gather, RPM packages contain pristine upstream sources
> and a patch file which patches them for RedHat during the build
> process.
RPM (which is a rewrite of a descendent of pms) uses a ".spec" file
to control package building. The spec file lists "pristine" sources
and patches (whether supplied or Red Hat produced). A "prep" section
of the spec file describes how to unpack the sources and apply the
patches. There are a couple of macros that help you do this without
write a lot of "zcat ... | tar ...". For example:
%prep
%setup
%patch -p1
The %setup macro can take a number of arguments, including "-n <name>"
which is used when the tar file unpacks into some directory other than
<packagename>-<version>. Other options take care of creating directories
and cd-ing into them for tar files that do not include a "root" directory.
Some additional sections are "build" and "install", which are just
snippets of shell script to do the obvious.
We've found this setup to be quite easy to manage. If I need to make
a few changes to a package, I can do `rpm -bp <specfile>' which does
the prep section, make my changes, (re)generate a diff against the
.orig files, and then `rpm -ba <specfile>' to rebuild both the source
and binary packages. All the while the pristine sources are preserved,
and the patches and spec file contain a complete record of everything
I did to build the package.
> The paper talks a bit about pre and post install and uninstall
> scripts, talks about "marking" package files for installation
> (so as to omit docs, for instance).
Not sure what you mean by "marking package files for installation".
> It also talks about something
> called sub-packages, but I see no mention of dependency resolution.
Doing "subpackages", for lack of a better term, just means that you
can generate multiple binary packages from a single source package
(and thus a single spec file). All you really need to do is add
additional "files" sections to the spec file.
We currently don't do anything with dependencies or conflicts. Our
experience so far has been that it isn't as much of an issue, at least
when we have complete control over all the packages in the distribution.
Even so, we do have dependencies and conflicts "in plan".
RPM does a lot more than what I've mentioned here and I'd encourage
anyone who is interested to have a look at it or email me for more info.
RPM is available at ftp.pht.com in pub/linux/redhat/rpm, and at all the
Red Hat mirrors.
-Marc
Reply to: