Date: Thu, 2 Oct 1997 12:33:52 -0700 (PDT) From: Sean Eric Fagan <sef@Kithrup.COM> To: config@freebsd.org Subject: Re: Microsoft brainrot (was: r-cmds and DNS and /etc/host.conf) Message-ID: <199710021933.MAA23952@kithrup.com> In-Reply-To: <199710021510.AAA00515.kithrup.freebsd.chat@word.smith.net.au> References: 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
In article <199710021510.AAA00515.kithrup.freebsd.chat@word.smith.net.au> you write: >(Apologies for the list double-up, trying to make sure this goes to the > right places.) Note that I moved it to -config only. :) >> When you do this kind of ugprade, you want to make sure that any >> configuration local configuration changes are propogated to the new version; Oops. I must have been getting tired when I wrote that :). >> 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"? Okay, here's how what I do "works," for some definition of "works" :). The OS has the SysV packaging tools -- pkgadd, pkgrm, pkginfo, pkgchk, some others. The base OS is distributed as packages -- core, scde, compat, ftx, a bunch of others. The packaging tools maintain a database; this file has an entry for each directory and file in the packages that are installed. The format is something like: pathname filetype class mode owner group size checksum date pkg(s) filetype is 'd' 'f' 'l' 'c' 'b' etc. class is used by a "class action" script -- e.g., you might have a "kernel" script that does something special. I don't think anyone really uses it. mode, owner, group, and size are what you'd expect ;). checksum is a cksum of the file; and date is the time the file was installed in epoch seconds. The list of packages that 'own' the file then follows. Every file obviously belongs to at least one package (or else it couldn't get instlaled :)). However, a file could belong to multiple packages -- which ever package installed it most recently is the last one in the list. The pkgchk command will, given a list of packages, check the size, owner, group, checksum, and modificaton dates of each file belonging to the specified packages. If there is a discrepancy, it prints out a message. (And I've got an annoying awk script that then turns that into a simple list that i can use.) *Now*: how do I identify configuration deltas? A bunch of shell script and awk code that "knows" the formats of a bunch of files. Fortunately, most of the configuration files are fixed format, since they are read by some other program, so I can deal with those. Not all of them, unfortunately. We (FreeBSD) have the config files that jordan has been doing; those fit nicely into a scheme like this, fortunately. >> 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. I don't know how to solve this problem, I'm afraid. :) >> 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) You've hit the nail on the head -- what do you do in that case? You're *supposed* to, when you install and replace a file, keep the old one around. Not all packages do that; nor is it really a good thing for them to do that in all cases. Right now, at work, I pretty much do nothing. There is no way to tell with the current set of tools what's going on -- it just does not distinguish beteween the case of multiple packages owning the same file, and two different packages with two different files that just happen to have the same name. Because of this... when you run 'pkgchck core', with the 'dcore' package installed... it will not show libfoo.a as being modified. So what *do* you do? I really don't know. I can think of several things, but they'd require a serious change to the packaging tools we use at work, and that is... not likely to happen :). Fortunately, FreeBSD isn't hampered by that problem yet, which is why I am mentioning all of this. Meanwhile, I'm gonna have to go look at your romeo and juliet thingy, I guess. Reply to me, or the list, but not both, please. Sean.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710021933.MAA23952>