Slashdot Mirror


Painlessly Update FreeBSD

boarder8925 writes "Over at BSDnews, Steve Wingate has written an article on how to easily update FreeBSD. Wingate begins his article by saying, "One of the greatest advantages that *BSD has over other Unix variants is the cvsup/make world process. Unlike most Linux distributions it isn't necessary to wait months for a new version to be released for you to upgrade your system. The cvsup/make world process allows you to update your system at any time. I'm going to show you how to make the process as painless as possible." The article discusses the following: installing CVSup, choosing a cvsup server, configuring make.conf, and, finally, performing the upgrade. The piece is also available as a .pdf file."

6 of 123 comments (clear)

  1. Re:cvsup in C? by CoolVibe · · Score: 4, Interesting

    There's also cvsync, which is a good cvsup alternative, written in C.

  2. Re:Gentoo has this.. by UnseenEnigma · · Score: 4, Interesting

    The only issue with gentoo is the lack of a central binary repository like the redhat channels system (official anyway - chinstrap is decent for those willing to stray). It was discussed at great length several months ago and decided not to be created despite having the backend infrastructure already in place. The great advantage of gentoo, and in a way the failure of bsd (and pretty much every commercial linux) is the ability to choose complex compile and build options with ease. For this same reason and the fact a binary repository could never handle a fraction of the possibilities it was never created :(. If however you consider implementing gentoo in a work environment with say 10-100 systems they could all be set to use a central compile server to your organisation or/and through distcc compile kickass fast! Although installs of gentoo are a pain (hopefully better if the installer gets built) it is by far the easiest to update, and customise of any linux. And (big + for me) none of the bs of no or modified media players, browsers, burner software etc of suse, redhat or mandrake because of cautios legal practises. I've been finding more and more things i like about the portage system the more i use it. Any new reasonably popular package seems to make it on the tree in less than a day. If their is a piece of software that isnt on the tree u need (happened to me once) u can either find or make a ebuild and submit it for inclusion in the tree My Conclusions Ms Windows - ah get it away from me!!!! Evil Redhat/Suse/Mandrake - Better but canabalises some stuff and out of date packages The BSD Trio - Stable, fast, easy update, and faster update due to binary Gentoo - Stable, fast, easy update and more customizable due to all source (usually)

  3. Re:too many dependencies by Anonymous Coward · · Score: 1, Interesting

    The problem isn't too many dependencies, the problem is that all current package managers suck. If I'm trying to migrate to the newest GIMP, I must first resolve all the dependencies for the new GIMP. This is only a problem because I'm forced to do it all at once. I have to first remove all of the old packages I'm going to replace with the new GIMP's dependencies, meaning my current system is unstable based off of a pending upgrade of one package. After that, I can compile/install the new GIMP, but I also have to make sure that none of my other packages depended on specific old versions of libraries that I might've just replaced. These are the sort of problems package managers are supposed to solve.

    Instead of lumping everything together in /usr/local, wouldn't it be better if packages binaries were separated by directory as well as symlinks to library dependencies? For example, if GIMP-2.0 installed to /usr/pkg/gimp/gimp-2.0, then I don't have to worry about removing the old GIMP at all. It doesn't matter if it takes it a week to compile, because I still have a working version of GIMP and all of its dependencies in place. Furthermore, instead of linking the GIMP binaries to /usr/local/lib/libgtk.so.0 (or whatever), it could be linked to /usr/pkg/gimp/gimp-2.0/dep/libgtk.so.0 which could then be made to point to any specific version of GTK2 I wanted. Dividing the various programs and libraries by source package makes the most sense of all, because that's how they're installed. Under a system like this, there's no cause to worry about what library version you have installed because they don't conflict.

  4. Issue #3?November 9, 2003 by beefdart · · Score: 4, Interesting

    I was scanning this... Got 1/2 way through and was wondering if he stole it, cause I swore i read it somewhere.

    Then I realized: Issue #3?November 9, 2003

    How the hell is this news? I love FreeBSD, its all I use. the only thing dead about it is bsd.slashdot.org

  5. Re:Anonymous Coward's Guide to Updating Debian by dasunt · · Score: 2, Interesting

    Yes APT is great. It's easy to use and requires less effort than the FreeBSD upgrade process but it's too bad Debian stable is so hopelessly out of date.

    Three words: "End of Life"

    If we are looking at updates, the last extended support release of FreeBSD was 4.8, which was released in April, 2003.

    Its end-of-life is March, 2005.

    Debian Potato was released August, 2000 and end-of-lifed in June, 2003.

    Debian Woody was released in July 2002, and, assuming that tradition holds, will be supported til at least May 2005. [ Debian seems to keep security updates going for one year after the date of the next release. ]

    Its rather nice not to change software in 3 years or so. ["Change" as in "new software version" -- debian does security patches, but they are backported to the version that ships with the release to minimize breakage. ]

    Ne'ermind that binary upgrades are damn nice.

    [ Don't feel bad -- OpenBSD has a lifespan of 1 year on its stuff, and no binary updates, which *really* annoys me -- otherwise its a fine OS which I like to use. ]

  6. Ports upgrading is more painful by cpghost · · Score: 2, Interesting

    Upgrading the base system is great and it works most of the time. I'd only wish cvsup/cvs were able to fetch a consistant source tree, but as long as CVS doesn't provide some kind of ACID semantics, it would be very hard to do so. There's always the risk of updating /usr/src in the midst of a commit.

    The ports are actually more painful to upgrade than FreeBSD proper. portupgrade does a great job at this, but it's not a panacea. First of all, portsdb -uU takes a hell of a time to generate a new INDEX.db, then you still have to fix some stale dependencies etc... This is the same problem as with Linux distros, and there is no easy solution to this.

    --
    cpghost at Cordula's Web.