Dennis Clarke wrote:
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]
Everyone who thinks he can improve something should go ahead and JOIN
BLASTWAVE.
Or build up his own stack.
Rather than complaining on public lists.
Martin Bochnig
[EMAIL PROTECTED]
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
