> Jason Ozolins writes: >> Blastwave package upgrade == package remove followed by package install. >> Not like, say, RPM's handing of upgrades at all. The service stops while >> the upgrade happens. Not to mention, some of our config files got creamed >> (this is really the packager's problem rather than inherent in SVR4 >> packages). This kind of explains why Sun puts out _patches_ rather than >> new versions of packages - because applying the latter can't be done >> easily to a running OS instance. SVR4 package management just wasn't >> designed to work the way that people expect package management to work >> these days. > > Not true on both counts. > > A Solaris upgrade (as opposed to patches) uses packages. The > difference is that the upgrade process uses SVr4 'admin' files when > necessary. Blastwave could do this with "instance=overwrite," and > probably should, but it doesn't.
Well let's take a look at this a bit closer. suppose we have a package called CSWfoo and the package prototype file looks like this : i pkginfo i depend i copyright d none bin 0755 root bin f none bin/foo 0755 root bin f none bin/bar 0755 root bin d none share 0755 root bin d none share/foo 0755 root bin f none share/bar/foo.dat 0444 root other We create a package and then roll it out. We then need to release an update which replaces the bin/foo binary as well as the share/foo file but affects nothing else. In a perfect world this would be a "patch" and not a package. At some point in the future another release comes along which now includes the amazing upgrade called foobar and its also specially built for AMD64 Opteron's as well as ye old 386 and the pentium_pro. What does the prototype file look like now ? i pkginfo i depend i copyright d none bin 0755 root bin f none bin/foo 0755 root bin f none bin/bar 0755 root bin f none bin/foobar 0755 root bin f none bin/amd64/foobar 0755 root bin f none bin/pentium_pro/foobar 0755 root bin f none bin/i486/foobar 0755 root bin d none share 0755 root bin d none share/foo 0755 root bin f none share/bar/foo.dat 0444 root other So now we have some new binaries, some data files that have not changed, some binaries that are the same again. Patch or Package ? The current method we employ is to remove the whole collection and use the standards compliant SVR4 tools to achieve this. Then install the new package entirely and then move on. The question on the table that needs to be looked at would be "is this optimal or even reasonable?" Dennis Clarke [EMAIL PROTECTED] _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org