Date: Sun, 8 Dec 2002 09:45:55 -0500 From: David Magda <dmagda@magda.ca> To: Aristedes Maniatis <ari@ish.com.au> Cc: freebsd-stable@FreeBSD.ORG Subject: Re: update strategies Message-ID: <20021208144552.GB269@number6.magda.ca> In-Reply-To: <2E37135F-0AB4-11D7-B2B7-003065A9024A@ish.com.au> References: <867kelp9t9.fsf@number6.magda.ca> <2E37135F-0AB4-11D7-B2B7-003065A9024A@ish.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 09, 2002 at 12:51:41AM +1100, Aristedes Maniatis wrote: > OK. This is where I get confused. I thought that the point of putting > these applications into the base FreeBSD distribution was that they > need to be tightly integrated into the OS. I understand that this is > critical for basic system tools like "adduser". It appears this makes > it important to build the whole distribution together (buildworld) and > not get one tool out of sync with the rest. Well think of it this way. You cvsup to get the up-to-date and do a buildworld. The next day an advisory comes out for tool XXX. The problem is that there exists an off-by-one remote buffer-overflow on line Y of some file in program XXX. A fix is released and incorporated in CVS. All that's changed between the previous day's source today's where the diff file would be: - strcpy( dst, src, MAXDATA); + strcpy( dst, src, MAXDATA+1); (Yes I know, *really* contrived example, but....) For that one change are you going to do a buildworld? Not really, it would be easier to go into program XXX's directory and recompile just it. Stand alone programs can usually be compiled by themselves. Things that touch a whole bunch of stuff (libraries, PAM, gcc, etc.) should be followed with a buildworld. It all depends on how much has changed since your last buildworld. If you cvsup weekly but not much has changed in way of functionality are you going to bother with a buildworld? Not really. However, if one of the updates is a fix for an exploit, another is a new feature to ls(1), a third is some documentation fixes to the intro(7) manpage, and the fourth is some indenation changes (but no functionality changes) to src/sbin/kget/kget.c what are you going to do? Personally, I would simply rebuild the fixed program. > But if this is not the case, and we are supposed to build portions of > the /usr/src/ without rebuilding the whole thing, why aren't these > tools in /usr/ports? Many of the utilities (bind, ssh, Kerberos/Heimdal, etc.) already are in the ports. Just because people want to have more control over how things are installed than is generally available in the base system. Also for the people that want to do what you do. When the advisory for BIND 8 came out a couple of weeks ago I know an admin who installed BIND 9 for the ports until version 8 was fixed. When 8 was fixed in CVS he updated it and went back to it. Why? Because with ports you have to fiddle with knobs, and look at CVS logs to see when things are updated, etc. With the base system the FreeBSD developers do a good of making sure things (generally) "just work". Said admin used to use Linux heavily (Slackware). He liked the simplicity of Slackware that most of the other distributions lacked. Even Debian which has an awesome way of updating the distribution, but there is a certain "way" of doing things. He doesn't like that. Now, every try updating glibc on a Linux distribution? Unless you have magic utilities (Debian, etc.) that do things for you it's a pain. With FreeBSD you just, cvsup and re-install: no fuss, no mess. Even when I went from 4-STABLE to 5-CURRENT on a test box it was simply a matter of cvsup'ing and re-installing. Do you know what I had to go through when I was using Linux and went from GNU libc 5 to GNU libc 6? And another time, from a.out to ELF? Ugly. > I'm new here, so I'm not telling you how to suck eggs. Perhaps there > are historical reasons for this hierarchy. But I want to make sure I do > the right thing. Is this the safest approach: [...] I'll let others comment on this procedure: I'm not experienced enough with admin'ing boxes yet to really say. -- David Magda <dmagda at ee.ryerson.ca> Because the innovator has for enemies all those who have done well under the old conditions, and lukewarm defenders in those who may do well under the new. -- Niccolo Machiavelli, _The Prince_, Chapter VI 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?20021208144552.GB269>