Date: Sun, 13 Jun 2004 23:52:04 -0500 From: "Matthew D. Fuller" <fullermd@over-yonder.net> To: Ladislav Bodnar <distro.watch@msa.hinet.net> Cc: freebsd-stable@freebsd.org Subject: Re: keeping my freebsd secure... THANX Message-ID: <20040614045204.GB15566@over-yonder.net> In-Reply-To: <200406141131.51215.distro.watch@msa.hinet.net> References: <pan.2004.06.12.09.01.59.52173@babysnakes.org> <Pine.LNX.4.58.0406132246220.10258@sparc64.devnet.co.uk> <1087170692.20776.16.camel@parker.babysnakes.org> <200406141131.51215.distro.watch@msa.hinet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 14, 2004 at 11:31:51AM +0800 I heard the voice of Ladislav Bodnar, and lo! it spake thus: > > In all honesty, I don't feel confident about upgrading an entire > system by compiling from sources. Maybe it's because I've been > bitten by upgrade problems on Gentoo, but also because, from > whatever little experience I have with FreeBSD, compiling from > sources can fail on FreeBSD too. My logic dictates that the binary > packages provided with a RELEASE are well-tested, so that everything > works together nicely. Why bother with compiling? > > Anybody cares to comment? The ports INDEX file for 4.10 release lists 10,796 ports. I've got 354 ports installed on my workstation, but let's pretend that an average system will only install 50. That means the number of possible permutations will be approximately 10,746^50 (actually more, since it'd be 10,796 * 10,795 * 10,794 *... but I'm jumping down to 10,746 to lowball it and be easier to calculate). 10,746^50 is a 204 digit number. If we assume that only one out of every million of those combinations is reasonable, that still leaves 3,650,411,396,581,559,362,879,249,467,190,229,597,059,899,426,193,483,642,569,249,585,031,431,662,936,103,076,048,636,266,422,245,971,453,527,168,401,084,361,122,022,674,779,277,721,175,179,289,262,473,970,567,184,765,108,865,603,416,304,860,138,423,380,665,880 possible combinations of packages. I wouldn't call that a problem space that can be reasonable submitted to "well-tested". It comes down to a question of how "well-tested" you want. A new release isn't going to end up in ports until whoever it is that actually writes the program releases a new version. And until whoever maintains the port has satisfied themselves that it doesn't break anything, for whatever level of satisfaction they require. For instance, it's can basically be taken as a given that the version of PHP in the ports tree will NEVER be updated unless it works with Apache. And, while less of a certainty than the above, the chances of Apache being updated and not working with PHP are extremely low as well. The chances of a conflict with PHP and the Apache-frontpage port are probably better, if still small. And so on down the line. Around a release, the ports tree tends to undergo a fairly extensive freeze, which means that there's a higher assurance of obvious problems being fixed. But then, obvious problems tend to get fixed fairly quickly at any other time as well, particularly in common applications. There's not really any more assurance than normal against more subtle interactions. Me, I just pay attention. I watch the lists. I usually don't upgrade things they day after a new version appears. Or even the week after, unless there's some pressing need. If something common is broken, it may well already be fixed by the time I notice it. And I stick my hands in to fix broken things that I come across where necessary. I've never had any major problems along the lines you seem worried about. That doesn't mean you won't, of course. Doesn't mean I won't have a whooper next week, for that matter. But that's what makes life fun 8-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040614045204.GB15566>