On 6/25/07, Brian Gupta <brian.gupta at gmail.com> wrote:
> (RPM can be replaced with the package manager of your choice)
>
> Why package software using RPM when Solaris has its own format?
>
> Package Database
>     Solaris stores the package database in /var/sadm/install. This
> means that even though the install directory, e.g. /usr/local, may be
> NFS exported to a number of clients, only the machine it was installed
> on can query or delete the package.

(Isn't that the way it should be?)

Solaris stores the packages files relative to the install root, which doesn't
have to be /. As long as you keep the relative directory structure the same,
you can install and manage things anywhere you like.

>     RPM can store its database anywhere, for example,
> /usr/local/rpm/db. With the database in this directory any client
> mounting /usr/local can manage the packages.

See above. You can't do exactly this, but then it's fraught with danger
anyway (client and server can disagree on the view of the world so
things get out of sync).

One way it works in Solaris is that you go

pkgadd -R /usr/local

and all the files get /usr/local stuck on the front - both the installed
files and all the packaging stuff. So you would end up with something
silly like /usr/local/usr/bin/ssh, and you would have to make sure that
the files you installed would actually work relocated like that. (The
normal use for this is something like a diskless client where the relocated
path gets mapped back to / on the client.)

> Package Signatures
>     RPM Packages have support for MD5 and OpenPGP signatures stored
> right in the files.

Solaris supports signed packages and patches.

> Package Verification
>     RPM has the ability to verify installed packages to detect
> corruption and or tampering. RPM checks the permissions, ownership,
> md5 checksums, and size of each file.

And timestamps. SVR4 uses regular sum rather than md5 (showing
its age, I guess).

> Package Documentation
>     I used to keep a notebook with the instructions for creating every
> package I built. This included configure options, files that needed
> patching, etc. I would always forget if there was some quirk about the
> software the next time I had to build it not to mention optional
> things that were enabled or disabled.
>
>     The beauty of RPM is that all of that information is stored in the
> Source RPM when the package is built. That basically makes it
> self-documenting.

Assuming you have the source RPM. Personally I would rather the
software itself could tell me important things about how it was built
rather than having to go to some separate source, but you can do
exactly the same thing with some of the package building tools
in Solaris.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

Reply via email to