(Apologies for the list double-up, trying to make sure this goes to the
> This is something I do at work -- making sure that it is possible to upgrade
> the OS without having to shut down. (There's a reboot to get to the new
> kernel, of course.)
> This is *hard*. Mainly because nobody bothers writing support for it ;).
Heh. Not wrong there.
> When you do this kind of ugprade, you want to make sure that any
> configuration local configuration changes are propogated to the new version;
> you want to remove any old files that are obsolesced (you can just remove
> any non-modified-configuration file, if you want instead); and you need to
> then install the new versions.
How do you identify configuration deltas? Do you use a parameter
database and version parameters, or just diff "original" against
> You also then have to deal with any dependencies that the old package had,
> or possibly packages that depended on the old package (since these
> dependencies might not hold true for the new package).
This last is one that bothers me somewhat. The best I can come up with
is to steal the major/minor versioning concept that's used with shared
libraries. If foo-1.2 depends on bar-1.3 and you try to upgrade to
bar-1.5 that should be OK, but if you want to upgrade to bar-2.0 this
should require a simultaneous upgrade of foo to a version that's
compatible with bar-2.0. This upgrade may be nothing more than a minor
bump that comes with new control files indicating that it's compatible
with either bar-1.x or bar-2.x of course.
> Lastly, in our case at work, we should deal with files that are in multiple
> packages. (Consider /usr/lib/libfoo.a, which when the OS was installed, was
> in the 'core' package; later, however, the 'dcore' package installed its own
> version of libfoo.a, so now the file either belongs to the 'dcore' package,
> or to both the 'core' and 'dcore' package; now what happens when you remove
> the 'dcore' package? The 'core' package? What happens when you replace
> either but not both package?)
Removing one or the other is easy; the reference count on the library
falls but does not hit zero and it stays. More interesting is when you
install the dcore package and the libfoo.a file is *newer*; which one
do you keep? (Actually this is very similar to the "replace" question.)
I would really like to know how you handle this. 8)
> I did, btw, suggest to Jordan, a while back, that all the "distributions"
> should be treated as packages. I don't know if he remembers :).
Yes, he does. We all agree that it's the right way to do it.
> I personally think the way to do that is to have an API for the utilities --
> something like SMTP or NNTP, I think. (Not socket based, but two-way pipe.
> Terry gave an example of this about two or three years ago, I think.)
Learn Tcl. Criticise the node-and-method interface Juliet uses. It
sucks for manual control of course.
> This doesn't mean that everything has to accept only the same commands -- an
> 'add user' program is going to have some different requirements from a 'add
> package'. But there should be a common interface, so that the 'add user'
> utility and the 'add package' utility can all use the same GUI wrapper.
.admin.users add <username>
.admin.users.<username> set <attribute> <new value>
etc. Note that I'm not sure I buy adding a node for every user, even
with the lazy tree expansion I currently use. Even on a hairy system
adding thousands of user nodes is going to hurt a little.