Jason Ozolins writes:
> > Jason Ozolins writes:
> > 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.
>
> What are the two counts? My supposed misunderstanding of patches vs
> packages is one, but I'm not sure which of my other statements is supposed to
> be bogus.
It doesn't explain why we use patches, and the existence of a running
instance doesn't have much to do with it.
Internally, patches use what are called "sparse" packages. If you
look inside a patch, you'll see bunch of somewhat ordinary-looking
packages. What's special about them is that they contain only *some*
of the files that were in the original package -- specifically, the
files that changed. The system relies on the fact that it can
overwrite the package and only those files will be touched.
> > necessary. Blastwave could do this with
> > "instance=overwrite," and
> > probably should, but it doesn't.
>
> Umm, I think we're writing at cross purposes here...
Indeed.
> Remove package, shared libs,
That's not correct. It's possible to use the admin(4) file to get a
different behavior out of pkgadd.
> kill daemon for duration of upgrade, [probably killing running telnet
> sessions in the process]
That *may* be necessary, but it has essentially nothing to do with
whether you're using a package or a patch.
The key issues are not related to the delivery mechanism, but rather
due to aspects of what's being delivered. The packaging system (which
is used by patching under the covers) always writes to a new file and
then moves the object into place. This means that it's actually safe
to do an overwrite-install of a package while the object is running,
provided that:
- the object already has all the files (including shared libraries)
open that it's going to need, and isn't going to lazy-load or
dlopen after you've started the upgrade process.
- any other changes made to the system as a part of the package
install process (such as rewriting configuration files) are not of
a nature that will "confuse" this running process.
It's in enumerating those issues, and following the logical chains
through other libraries and options, that the complexity arises. This
is why many patches from Sun recommend single-user (to make sure that
nothing's running, as we can't guarantee the consistency above) and
quite a few say "reboot immediate."
Blastwave's approach has essentially the same underlying issues, even
if the user experience is different.
> reinstall package, maybe cream config files somewhere in the process.
As for configuration files that get removed or damaged in the upgrade
process, that's an upstream packaging error. The package creator has
to be aware of how the upgrade will take place, and plan for it so
that the necessary information isn't nuked in the process. Inside
Sun, we handle this problem through a variety of review and testing
procedures (the ARC is part of this, but there are many other parts).
I'm not sure how blastwave handles review of packaging rules and
upgrade planning -- that's something you should take up with them (and
probably not on this list).
The same is actually true for patches.
> complain. But my original post was just trying to point out that
> the existence of Blastwave and Sunfreeware is not enough for Solaris
> to win mindshare among folks who have used Linux distros with decent
> package management, an example being my co-workers and management.
> If I failed to understand some nuanced differences between Solaris
> patches and packages, it really doesn't detract from that point.
I strongly agree with that. The quality of the upgrade experience has
an enormous impact on whether a platform is viable at all in a
production environment.
I don't think, though, that "decent package management" is entirely or
even primarily a feature of the packaging software itself. A huge
amount of the effort rests on the project teams who package and
deliver the software -- if they don't think through the upgrade
scenarios clearly, there's not much that even the most sophisticated
packaging tools can do to save them.
Good tools can help, but there's no magic bullet here.
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-discuss mailing list
[email protected]
