Hi,
Chris Ricker wrote:
I think it's perhaps more clear, particularly if you're wanting to compare
lots of different systems / cherry-pick from available implementations, to
think of the needed functionality as 3 different things:
* building packages
* installing and removing packages
* managing packages[1]
in Solaris, these three are:
pkgmk (sorta, though that's not a managed build system in the sense of the
competition)
pkgadd / pkgrm
Sun Update Connection
Sun Update Connection does not manage packages, it just manages
patches[1]. It is possible to add and remove packages in a patch using
patch scripts, but its tricky to do correctly. apt-get, pkg-get etc. all
replace the package.
[1] where by "managing packages" I mean some sort of
meta-installer-remover that deals with things like autoinstalling package
dependencies, updating installed packages automagically, etc. The category
name's not very good but hopefully the examples indicate the functionality
split between it and just "installing and removing packages"
I'd label it as 'sustaining the system' (apologies if that sounds
waffley!). 'Managing packages' really boils down to how you choose to
sustain and support your distribution.
You mention removal of packages, which is something that doesn't get
enough attention. I'm out of touch with how debian et. al. handle this
but it should be possible to roll back changes. Say a user encounters a
problem and wants to remove the last change to a package (not
necessarily the last change to the system).
Lets assume they went from package/tool X-3 to X-4. X-4 requires at
least Y-5, and the user had Y-3 installed.
In solaris, using patches, the X-4 patch will require the Y-5 patch. So
when you install X-4, Y-5 is installed first. Now if you need to revert
your system back to the previous state you just remove X-4 and Y-5,
leaving you with Y-3 and X-4. The patch backout data is stored on the
system as is the previous state of the system, which makes this easy.
Last time I looked at linux distro package management the system did not
have a way of recording what the previous state of the system was (I'm
sure I'll be corrected if this has changed!). 'rmp -q' will tell you
what is installed but not the list of what was,
/var/sadm/pkg/<pkg>/pkginfo on solaris will list all the changes
including backed out changes (the PATCH* lines).
You might remember that you had X-3 installed and so you remove X-4 and
install X-3. Examining X-4 you see it requires Y-5, but how do you know
what version of Y you had previously to get your system back to the
original state? Even if you had a record on the system that it
previously had Y-3 you could retrieve it from your on line repository,
but that information needs to be captured. I purposely used a
requirement in the example to show how this can get complicated.
I know that patchrm nor sun update manager automatically remove Y-5 if
you remove X-4, nor should they. But the point is that if you know just
the additions you made to the system (patchid's added) you can roll back
to the previous state, you don't need to explicitly know the original state.
Apologies to the linux distros if they can handle reverting packages
back to a previous state, its been a while since I looked. But in any
case its something else to think about for a purely package based approach.
Cheers,
~Al
[1] yes you use patches to update packages and in that sense sun update
connection is managing packages. Thats probably what Chris meant, but
I'm clarifying it just in case!
--
Albert White - Patch System Test - SUN Ireland
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
