Date: Mon, 22 Mar 1999 23:11:58 +0000 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Mike Meyer <mwm@phone.net> Cc: stable@FreeBSD.ORG Subject: Re: Musings about tracking FreeBSD... Message-ID: <19990322231158.A68035@rucus.ru.ac.za> In-Reply-To: <Pine.BSF.4.05.9903221142550.414-100000@guru.phone.net>; from Mike Meyer on Mon, Mar 22, 1999 at 12:11:22PM -0800 References: <199903220825.IAA00589@keep.lan.Awfulhak.org> <Pine.BSF.4.05.9903221142550.414-100000@guru.phone.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon 1999-03-22 (12:11), Mike Meyer wrote: > > > 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 If you have a local copy of /usr/src, simply use anoncvs, and cvs diff the pertinent bit of the system if you're really in need of the patch. The point in running -STABLE is that you're getting these little patches all the time, and you don't have to worry about applying them yourself. > 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. I must say the same thing about other operating systems that don't use CVS. I just don't understand how people survive without it, and I imagine CVS is much more of a functional gain than the ability to apply patches you get from a whole bunch of different people all around the world.. > 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. Depending on the level of changes, again, all these patches are available using CVS, and I think the cvsweb scripts are pretty friendly (or I may be comparing another project) in this regard. So, if you have a problem with sendmail in 3.0-RELEASE, and you need to fix it up, just run a diff, or just update that small section you're interested in. > 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. Possibly, but it all depends on what you're trying to do. I don't think -STABLE is all that geared towards people who couldn't be bothered to follow it. It's point in life is to allow changes to get integrated between releases, and thus people who are keen to get the cutting edge of the blunt edge should be following it. If you don't want the hassles, and the releases are doing it for you, great, just use the releases. Noone is trying to force you to use -STABLE, I'm sure. > 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. You might want to take this up in another email, as many people who might be interested in this as a problem might not have been interested in your Subject line, or initial content. > 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? Obviously reinstalling ports to make sure they know what they're talking to on the other end of a function call is an idea, but doesn't apply in most cases. As a general rule, anything that talks to hardware or memory a lot should be rebuilt. As for tools, it should be relatively trivial to write a script that takes a look at what's installed and then tries to install them again (using make reinstall). (Not that it's likely to be required) > Of course, that leaves things that weren't install from /usr/ports out > in the cold. Unfortunately that's a sad fact of life if you're not using some form of package management. > 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. On quite a few machines recently I went through and made sure we weren't running any old non-ELF ports, and upgraded as necessary. Since some of these ports had been installed since before I even came to this university two-and-a-half years ago, there doesn't seem to be anything that says that you should go through and update your ports every time you rebuild world. I'm not an expert on the matter, but I'm more impressed with the "assuredness" the world process gives me, compared to the other methods where I've managed to make a few mistakes before. Again, whatever _you_ feel comfortable with - it's your machine, and noone is going to tell you what you _must_ do, but evaluate their advice, and don't come crying if things explode violently. Neil -- Neil Blakey-Milner nbm@rucus.ru.ac.za 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?19990322231158.A68035>