Date: Fri, 03 Oct 1997 00:40:45 +0930 From: Mike Smith <mike@smith.net.au> To: chat@FreeBSD.ORG Cc: config@FreeBSD.ORG Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199710021510.AAA00515@word.smith.net.au> In-Reply-To: Your message of "Tue, 30 Sep 1997 22:54:53 MST." <199710010554.WAA21894@kithrup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
(Apologies for the list double-up, trying to make sure this goes to the right places.) > 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 "current"? > 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. mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710021510.AAA00515>