On 08/01/12 05:49, Edwin Beasant wrote:
Hi all, I'm sending this to make sure I have the right end of the stick:What I wish to do is to make one package obsolete and have it removed at update, to clear the way for a new package, but not perform a package rename. I believe that I can achieve this with the following line in the old package' s manifest: set name=pkg.obsolete value=true And removing the remaining content of the manifest that delivers the files. The twist to this is that the package that is replacing this one (note: *not* a direct replace, so a package rename is not appropriate here) is in a different consolidation. It seems ugly, but: Would it be appropriate to first remove the code and manifests from the old consolidation, and simultaneously introduce an 'obsoleting' manifest to the new consolidation, along with the replacement code and manifest? I'm envisioning that the following would happen: 1. The package is removed from the old consolidation's incorporation (no longer present in the build) 2. The obsoleting manifest is picked up and built into the new conolidation's incorporation 3. The 'obsolete' package is then removed from the system on update. 4. The way is now clear for a manual installation of the replacement package if required. Are there any parts of this that I have completely misunderstood?
Look at usr/src/pkg/README.pkg in ON, there's a nice writeup of the general process to follow there.
You seem to have the general idea right though. -Shawn _______________________________________________ userland-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/userland-discuss
