Dennis Clarke writes:
> Do you feel or even think that we can come up with a way to maintain the
> contents database file as well as perhaps design a better way to roll out
> software packages?
Yes.
I think it'd be helpful to have a "check pkgmap diffs" mode for
pkgadd, so that can remove stray files after performing an
"instance=overwrite" type of install. One of the benefits is that we
could eliminate one of the possible failure modes: at the end of a
pkgadd, you'd either have the new package installed, or the old one
would remain. It wouldn't be possible to remove the old one and fail
to install the new.
Another is that it'd be possible to migrate configuration files and
the like as software versions change. Right now, we can't know when
you do pkgrm whether you'll ever install a new version of the same
package, so the best we can do is just leave those files on the system
during pkgrm.
I think the rough parts are:
- Figuring out what to do about older releases, as blastwave
supports S8 and up, and we're unlikely to be integrating new
pkgadd features there. We need a simple way to fall back to the
older remove-and-install scheme.
- Deciding what to do about files that move between packages.
- Enumerating and handling the other corner cases, such as a package
with a previous instance delivering "usr/lib/foo", a new instance
without "usr/lib/foo" in its pkgmap, but with a postinstall script
that does installf on usr/lib/foo.
For the first one, I would propose two things:
1. For packages that don't make reference to the to-be-removed files
in preinstall, postinstall, or class action scripts, there's no
difference between the two mechanisms. This is, I think, where
we are today.
2. For those that end up referring to those files, they'll need to
be separated into "pre-S11" and "post-S11" versions.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
