> I happen to be fond of our pkg system and I've written many an
> updateable package (where you update by pkgadd w/o a prior pkgrm).
>
> SUNW packages, however, aren't -- you have to pkgrm + pkgadd.
While some packages have, on their request, their old version removed
as part of the upgrade process, in general that isn't true. We
certainly require packages in ON to be upgradeable [1].
> The support for updateable packages could be improved to where it's easy
> to use, and our packages could be retrofitted to support this. A lot of
> work, that, but a new packaging system won't be any less work.
>
> FWIW, the main problem with pkg updating is that by default it's off and
> by default pkgadd'ing a pkg that is already installed results in a new
> "instance" of the pkg, but for most pkgs multiple instances are not
> meaningful. Yes, you can set MAXINST=1 in pkginfo, but we generally
> don't. And yes you can change the default pkgadd behaviour to
> "instance=overwrite" (see admin(4)). But that's not enough: some/many
> pkg scripts will need to know when a pkgadd is being added vs. updated.
I think most packages that need to know that they're being upgraded
aren't going to work right if you remove them first. Usually the
bits that need special treatment on upgrade are the administrator-
editable parts you need to keep around.
In addition to not providing an easily accessible interface for
upgrading packages, the biggest functional gap (and perhaps this is
what your packages try to work around) is the packaging tools
themselves don't track which files need to be removed when
overwriting an existing package. Solaris upgrade relies on an
external mechanism to strip the system of unnecessary files.
> But all this is for another list...
Word.
Dave
[1] The last time I tried, I was able to do a whole-ON upgrade using
just pkgadd.
