On Thu, May 15, 2008 at 12:40:24PM -0700, Paul B. Henson wrote:

> How thorough is package removal? Will removing a package result in a system
> identical to one in which that package was never installed in the first
> place? Or will there be miscellaneous cruft left?

As long as the image hasn't been booted yet, then there should be no cruft,
and an uninstall should bring the system back to the state which it was in
before the install.

As you saw, once you boot the image, all bets are off.  But we do try to
move the cruft out of the way.

I've talked to Bart about the idea of marking a directory as being owned
exclusively by a package, and that on removal, all contents of the
directory are removed, regardless of whether they're owned by the package
(obviously, other packages would need to be prevented from putting anything
there).  I wonder if that's what the "x"-type files in SVr4 were supposed
to do, but as far as I can tell from the code, they're treated identically
to "d"-type files.

> An interesting new use of the lost+found directory convention :). I assume
> in this case var/log/gdm was owned by the package being removed, and
> contained files not part of the package. So it moved the files elsewhere,
> and then deleted the directory.

Yes, precisely.

> On another note, how similar are package names between S10U5 and
> openSolaris? I already have a pretty good list of packages I want
> installed under S10U5, would that be roughly similar to the openSolaris
> equivalent?  Or would it be better to ignore that list just start from
> scratch?

You're better off starting from scratch.  First, OpenSolaris is based off
of Nevada (build 86), so there are lots of differences between S10 and
Nevada that are baked in.  And then we've gone and coalesced as many
root/usr packages as we could, plus a handful of other ones.

In many cases, you can look for legacy actions which indicate which SVr4
package(s) the contents came from, but I'm dubious that this will survive
the greater package rewhacking that will be coming (which will definitely
require a rewrite-from-scratch on your part).

Danek

Reply via email to