> > 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. > > Yes, but this too is something that pkgadd could just learn to do.
I (representing the peanut gallery) wholeheartedly agree :) > Basically I think we're talking about a handful of improvements to > pkgadd: > > - a command-line option to force upgrade/overwrite of a given instance > (for pkgs w/o MAXINST=1) Side note: Though instances are a weird construct whose purpose I never quite understood, my impression is that making any connection between MAXINST=1 and upgrading/upgradability is semantically wrong. I think having an option which set instance=overwrite without needing to specify an admin file would be nice. > - a command-line option, possibly the same as above, to force removal > of files that are not in the new version of the pkg (IIRC patching > uses sparse package updates, where this would be bad as a default) In most cases, though, that's what I want when I upgrade a package. I'd argue this behavior should be the default when using your 'pkgadd -u'. Implementing this correctly is a little tricky, though. The thing which makes it difficult is that files which move between packages should be left alone. You would need to support taking a set of packages you want to upgrade, and compute the set of files to be removed based on the old and new contents of entire set. (Okay, not that tricky.) Doing this with the existing tools (and a little help from everyone's not-quite-public friend, /var/sadm/install/contents) is certainly possible. Unfortunately, I think the ease of doing so has resulted in the functionality not being sedimented into the packaging tools where it belongs. Dave
