Date: Mon, 22 Mar 1999 12:11:22 -0800 (PST) From: Mike Meyer <mwm@phone.net> To: stable@FreeBSD.ORG Subject: Musings about tracking FreeBSD... Message-ID: <Pine.BSF.4.05.9903221142550.414-100000@guru.phone.net> In-Reply-To: <199903220825.IAA00589@keep.lan.Awfulhak.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Mar 1999, Brian Somers wrote: > > > Running stable is preferable than release. But the targets are > > > buildworld and installworld. > > > > If you make regular backups of userland, that represents quite a bit > > of work. Since it rebuilds everything in userland, you wind up dumping > > all of userland with every backup, so you need to do some kind of > > special backup after doing an installworld. Putting it all together, > > that's enough work that I wouldn't bother doing it except every 6-8 > > weeks. But -RELEASE happens about twice that often. What's the point > > of tracking -STABLE under those conditions? > > Set COPY to -C in /etc/make.conf. From looking at make.conf and the various makefile bits in /usr/src, I think you mean set INSTALL to "install -C" (it's in the make.conf, but commented out). > > This all points to one of the most serious problems with the current > > release system - that patches seem to be considered impossible. On > > commercial OS's, or Linux, you see small distributions that fix a few > > things in userland (a security hole in Sendmail being a typical > > AFAIK, FreeBSD is never going to start making these sort of patches. > It only leads to the linux ``Sendmail doesn't work ? Ahh, you need > to install patch 1.2.3 from some.domain, but I wouldn't do that > unless you've first installed patch 1.1 from some.other.place'', or > even worse, the Solaris scenario where you can install individual > patches or you can install jumbo ``recommended'' or ``y2000'' patches > where the patch set that these words represent changes monthly.... First, just to make it clear - I'm not saying that FreeBSD *needs* a patch mechanism. Just that there seems to be a level of functionality I'm used to seeing that's missing. That said, your answer "the cure is worse than the disease" is perfectly valid. However, you chose the other extreme for your example of "the cure"; Sun works harder at not saying "That's fixed in the next release" than any other vendor I've dealt with. Which means you have things like patches to patches, and dozens of versions of a patch, and jumbo patches - which can make getting a patch installed harder than doing a system upgrade. Once you're willing to ask that people upgrade, the frequency of the FreeBSD releases means you will avoid the more extreme cases that Sun gets into. Further, all the sites I've dealt with dealt with this issue by 1) installing the patch on the systems that were being hit by the bug, then 2) adding the patch to the standard system install so new systems didn't get it. This isn't noticably worse than doing one system upgrade, and then just tracking the -STABLE tree for installing new systems. That said, the only real issue would be things that you want to install on most systems, even if they aren't obviously having problems that are cured by an upgrade. As far as I can tell, only security fixes meet that criteria. Possibly those are rare enough it's not a problem, and point releases do the trick? How common are point releases for such things? > > Unfortunately, I don't have a solution, even ignoring the problem of > > needing to find extra time to do that work. The main reason for doing > > this is to see if anyone else has ideas for a solution. > > Either use the -C install option as mentioned above or subscribe to > the commit lists and decide when you want to rebuild/install an > individual program. > > You can then do a ``make world'' every six weeks or whatever. Part of my point was that updating to -STABLE every six weeks or so - when -RELEASE is updated every 12-16 weeks - seems pretty pointless. However, I noticed another problem. If your syslog is sending log messages to a machine that you've shut down (for example, to do a "make installworld" on it), it stops logging until you restart it. Is this a bug? If so, I'll look into fixing it. If not, I can switch to the daemontools port. However, that brings up yet *another* level of problem. Even if you follow the correct procedures completely (or at least as completely as they have been specified here), you can still wind up with broken binaries from the /ports tree. In fact, the first time I did a system update, I did exactly that: update the source tree, build the world, install the world, build a new kernel, install the new kernel, run mergemaster, and reboot. Everything worked fine. Then I dumped / & /usr to disk and tried to burn a CD-ROM of those dumps for archival purposes - only to have cdrecord die in the middle with an illegal system call. Rebuilding cdrecord solved the problem, but this illustrates that the recommended procedure is incomplete - you need to reinstall all ports/packages as well, right? Is there a tool that inspects /var/db/pkg to automate that process? Of course, that leaves things that weren't install from /usr/ports out in the cold. Does anyone actually update all such things? Or do they do the more realistic thing, and just rebuild things that aren't from /usr/ports - or are, for that matter - when they break? Which would also be a perfectly reasonable attitude for /usr/src & make/make install vs. buildworkd/installworld, and which at least one person recommended to me in private mail. <mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9903221142550.414-100000>