Dan Price wrote:
>> postremove:  undo Gnome integration [[???]]
> 
> (shouldn't that be in preremove?)

Shrug.  I'm only reading the script; I didn't write it.  I think that 
particular one was in SUNWj6rt.  Perhaps I misunderstood it; it's a 
complicated script.

>> preremove:  unshare directory [[???]]
> 
> You mean unshare as in NFS sharing?  Why would (even the existing)
> packaging be doing this?

It's the JET package, supporting jumpstart installs.  I presume that as 
part of its installation and configuration it sets up one or more NFS 
exports to export JumpStart config data and install media, and that on 
uninstall it removes those exports.

Look at it another way:  NFS is another way to offer a network service. 
  You wouldn't look twice at a package that removed inetd.conf entries 
or rpc entries, so what's  weird about removing NFS exports?

>> preremove:  delete data directory [[???]]
> 
> Do you mean these are deleting user data?  Something else?  Could you
> elaborate?

Again, I'm only reading the scripts - I didn't write them.  However, I 
believe that this particular directory contains OS images that were 
downloaded and cached on the system.  It isn't clear to me whether 
removing it is correct or not.  (I actually have a bug outstanding on 
this question, since the Linux version of the product doesn't remove them.)

> I think we've posited the idea of a "datadir" or some such
> tag on a directory action which would indicate that the dir is a
> directory of stuff that should be cleaned up on removal of the last
> package delivering this action.

That sounds like it matches the usage here.  It certainly seems 
reasonable for a package to delete temporary data - caches and whatnot. 
  Whether it should delete user data or data that is expensive to 
recreate is not clear to me; I don't think Sun has a consistent policy 
on it. Our QA people get twitchy if our uninstaller doesn't leave the 
system in exactly the same state it was in when you installed the 
product, so they like us to delete _everything_.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss

Reply via email to