FreeBSD Operating System

Keeping up to date

Разбить на страницы
Показывать лекцию целиком

FreeBSD is constantly changing. The average time that elapses between changes to the source tree is in the order of a few minutes. Obviously you can't keep up to date with that pace of change.

In the following three chapters we'll look at how to keep up to date. In this chapter, we'll look at:

  • FreeBSD releases: how the FreeBSD project comes to terms with the rapid rate of change, and how it keeps the system stable despite the changes.
  • How the system sources are stored, and how you can update them.
  • In Chapter 32, Updating the system software, we'll look at how to upgrade FreeBSD to a new release, with particular reference to upgrades to FreeBSD Release 5, and in Chapter 33, Custom kernels, we'll look at building special kernels.

    FreeBSD releases and CVS

    The FreeBSD project keeps the entire operating system sources in a single master source tree, called a repository, which is maintained by the Concurrent Versions System, or CVS. It's included in most multi-CD-ROM distributions of FreeBSD. The repository contains all versions of FreeBSD back to Release 2.0 and the last release from the Computer Sciences Research Group of the University of California at Berkeley, 4.4BSD-Lite, upon which it was based. For copyright reasons FreeBSD Release 1 was not included, because at the time, as the result of the lawsuits described on page 8, it was not permitted to distribute it freely. That situation changed in early 2002, but it's now too late to include FreeBSD Release 1 in the repository.

    CVS is built on top of the Revision Control System, or RCS. RCS keeps multiple versions of files, called revisions, in a single RCS file. Each revision has a number indicating its relationship to the other revisions. The oldest revision has the number 1.1, the next oldest has the number 1.2, and so on. The RCS file contains the most recent revision of the file along with instructions for creating any other revision.

    In addition to this linear sequence, it's possible to update a specific revision in more than one way. The obvious way to update revision 1.2 would create revision 1.3; but it's also possible to create branches, which get numbers like1.2.1.1. Updating revision 1.2.1.1 would create revision 1.2.1.2, and so on. By contrast, the revisions with a two-part number are collectively called the trunk of the tree.

    Symbolic names or tags

    In addition to the numeric identifiers, each of which relates only to a single file, RCS allows you to attach symbolic names to specific revisions. CVS generally calls these names tags, and that's the term you'll see most often. FreeBSD uses tags to indicate the revisions corresponding to a particular release. For example, in the directory /usr/src/sys/kern, revision 1.13 of kern_clock.c, revision 1.12 of kern_fork.c and revision 1.21.4.1 of kern_exec.c participate in RELENG_2_1_0_RELEASE. We'll look at tags in more detail on page 588.

    RCS stores its files either in the same directory as the working fi les it is tracking, or in a subdirectory RCS if it exists. To avoid file name conflicts, RCS appends the characters, v to the RCS file, so the working file main.c would correspond to the RCS file main.c,v. For more details of RCS, see the man page.

    CVS is an extension to RCS that allows concurrent access, making it more suitable for projects involving more than one person. Unlike RCS, it stores its RCS fi les in a separate directory hierarchy, called a repository. Each directory in the working tree contains a subdirectory CVS with information on the location of the repository, the revisions of the working files and a tag if the revision isn't on the trunk.

    If you're a serious developer, there are a number of advantages to keeping a copy of the repository. If you're a casual user, it's probably overkill.

    FreeBSD releases

    There are four main versions of FreeBSD, each intended for use by different people:

    FreeBSD-RELEASE

    FreeBSD-RELEASE is the latest version of FreeBSD that has been released for general use. It contains those new features that are stable, and it has been through extensive testing. You can get it on CD-ROM. FreeBSD-RELEASEs are given a release number that uniquely identifies them, such as 5.0. There are three or four releases a year. A new branch is made for each release of FreeBSD.

    FreeBSD-STABLE

    FreeBSD-STABLE is an updated version of FreeBSD-RELEASE to which all possible bug fixes have been applied, to make it as stable as possible. Fixes are made on a daily basis. It is based on the same source branch as FreeBSD-RELEASE, so it has all the features and fewer bugs. It may contain additional features, but new features are tested in the – CURRENT branch first.

    Due to the frequent updates, FreeBSD-STABLE is not available on CD-ROM.

    Security fix releases

    Despite the name, FreeBSD-STABLE is subject to some problems. Every change to a source tree has the potential to go wrong. In many cases, you're more interested in keeping your system running than you are in getting minor bug fixes. FreeBSD also maintains a second " stable" branch consisting of the release and only very important bug fixes, including security updates. This branch does not have a well-defined name, but it's generally referred to as the security branch.

    FreeBSD-CURRENT

    FreeBSD-CURRENT is the very latest version of FreeBSD, located on the trunk of the tree. All new development work is done on this branch of the tree. FreeBSD-CURRENT is an ever-changing snapshot of the working sources for FreeBSD, including work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. Many users compile almost daily from FreeBSD-CURRENT sources, but there are times when the sources are uncompilable, or when the system crashes frequently. The problems are always resolved, but others can take their place. On occasion, keeping up with FreeBSD-CURRENT can be a full-time business. If you use -CURRENT, you should be prepared to spend a lot of time keeping the system running. The following extract from the RCS log file for /usr/src/Makfile should give you a feel for the situation:

    $ cvs log Makefile
    ….
    revision 1.152
    date: 1997/10/06 09:58:11;   author: jkh;   state: Exp;   lines: +41 -13
    Hooboy!
    Did I ever spam this file good with that last commit. Despite 3 
    reviewers, we still managed to revoke the eBones fixes, TCL 8.0 
    support, libvgl and a host of other new things from this file in 
    the process of parallelizing the Makefile. DOH! I think we need 
    more pointy hats - this
    particular incident is worthy of a small children's birthday 
    party's worth of pointy hats. ;-)
    I certainly intend to take more care with the processing of aged 
    diffs in the future, even if it does mean reading through 20K's 
    worth of them. I might also be a bit more anal about asking for 
    more up-to-date changes before looking at them. ;)
    

    This example also shows the list of the symbolic names for this file, and their corresponding revision numbers. There is no symbolic name for -CURRENT, because it is located on the trunk. That's the purpose of the line head, which shows that at the time of this example, the –CURRENT revision of this file was 1.270.

    So why use -CURRENT? The main reasons are:

  • You might be doing development work on some part of the source tree. Keeping "current" is an absolute requirement.
  • You may be an active tester, which implies that you're willing to spend time working through problems to ensure that FreeBSD-CURRENT remains as sane as possible. You may also wish to make topical suggestions on changes and the general direction of FreeBSD.
  • You may just want to keep an eye on things and use the current sources for reference purposes.
  • People occasionally have other reasons for wanting to use FreeBSD-CURRENT. The following are not good reasons:

  • They see it as a way to be the first on the block with great new FreeBSD features. This is not a good reason, because there's no reason to believe that the features will stay, and there is good reason to believe that they will be unstable.
  • They see it as a quick way of getting bug fixes. In fact, it's a way of testing bug fixes. Bug fixes will be retrofitted into the -STABLE branch as soon as they have been properly tested.
  • They see it as the newest officially supported release of FreeBSD. This is incorrect: FreeBSD-CURRENT is not officially supported. The support is provided by the users.
  • If you do decide to use -CURRENT, read the suggestions on page 622.

    Snapshots

    FreeBSD-CURRENT is available in the form of ISO (CD-ROM) images. From time to time, at irregular intervals when the tree is relatively stable, the release team makes a snapshot release from the - CURRENT source tree. They are also available on CD-ROM from some vendors; check the online handbook for details. This is a possible alternative to online updates if you don't want the absolute latest version of the system.

    Getting updates from the Net

    There are a number of possibilities to keep up with the daily modifications to the source tree. The first question is: how much space do you want to invest in keeping the sources? Table 31-1 shows the approximate space required by different parts of the sources. Note that the repository keeps growing faster than the source tree, because it includes all old revisions as well.

    Approximate source tree sizes
    ComponentSize (MB)
    Repository src/sys250
    Repository src1000
    Repository ports300
    Source tree /usr/src/sys110
    Source tree /usr/src450
    Source tree /usr/ports200
    Object/usr/obj160

    The size of /usr/src/sys includes the files involved in a single kernel build. You can remove the entire kernel build directory, but if you want to be able to analyze a panic dump, you should keep the kernel.debug file in the kernel build directory. This changes the size of /usr/src as well, of course. The other object files get built in the directory /usr/obj. Again, you can remove this directory tree entirely if you want, either with the rm command or with make clean. Similarly, the size of /usr/ports includes a few ports. It will, of course, grow extremely large (many gigabytes) if you start porting all available packages.

    If you're maintaining multiple source trees (say, for different versions), you still only need one copy of the repository.

    CVSup

    CVSup is a software package that distributes updates to the repository. You can run the client at regular intervals—for example, with cron (see page 151) to update your repository.

    To get started with CVSup, you need the following:

  • A source tree or repository, which doesn't have to be up to date. This is not absolutely necessary, but the initial setup will be faster if you do it this way.
  • A copy of the cvsup program. Install it with pkg_add from the CD-ROM (/cdrom/packages/Latest/cvsup.tbz).
  • A cvsup file, a command file for cvsup. We'll look at this below.
  • A mirror site from which you can load or update the repository. We'll discuss this below as well.
  • The cvsupfile contains a description of the packages you want to download. You can find all the details in the online handbook, but the following example shows a reasonably normal file:

    *default  release=cvs
    *default  host=cvsup9.freebsd.org
    *default  base=/src/cvsup
    *default  prefix=/home/ncvs
    *default  delete
    *default  use-rel-suffix
    *default  compress
    src-all
    ports-all
    doc-all
    

    The lines starting with *default specify default values; the lines that do not are collections that you want to track. This file answers these implicit questions:

  • Which files do you want to receive? These are the names of the collections in the last three lines: all of the sources, ports and documentation.
  • Which versions of them do you want? By default, you get updates to the repository. If you want a specific version, you can write:
  • *default tag=version
    

    version is a release tag that identifies the version you want, or . (a period) to represent the CURRENTversion. We'll discuss release tags on page 588.

    Alternatively, you might ask for a version as of a specific date. For example:

    *default date=97.09.13.12.2
    

    This would specify that you want the version as it was on 13 September 1997 at 12:20. In this case, version defaults to . (a period).

  • Where do you want to get them from? Two parameters answer this question: host=cvsup9.freebsd.org specifies the name of the host from which to load the files, and release=cvs specifies to use the cvs release. The release option is obsolescent, but it's a good idea to leave it in there until it is officially removed.
  • Where do you want to put them on your own machine? This question is answered by the line *default prefix=/home/ncvs. We're tracking the repository in this example, so this is the name of the repository. If we were tracking a particular release, we would use *default prefix=/usr. The collections are called doc, ports and src, so we refer to the parent directory in each case.
  • Where do you want to put your status files? This question is answered by the line

    *default base=/src/cvsup.
    

    In addition, the file contains three other lines. *default delete means that cvsup may delete files where necessary. Otherwise you run the risk of accumulating obsolete files. *default compress enables compression of the data transmitted, and *default use-rel-suffix specifies how cvsup should handle list files. It's not well-documented, but it's necessary. Don't worry about it.

    Which CVSup server?

    In this example, we've chosen one of the backup US servers, cvsup9.FreeBSD.org. In practice, this may not be the best choice. A large number of servers are spread around the world, and you should choose the one topographically closest to you. This isn't the same thing as being geographically closest—I live in Adelaide, South Australia, and some ISPs in the same city are further away on the Net than many systems in California. Look on the web site http://www.FreeBSD.org for an up-to-date list.

    Running cvsup

    cvsup is a typical candidate for a cron job. I rebuild the -CURRENT tree every morning at 3 am. To do so, I have the following entry in /root/crontab:

    #Get the latest and greatest FreeBSD stuff.
    0 3***./extract-updates
    

    The file /root/extract-updates contains, amongst other things,

    cvsup -g -L2 /src/cvsup/cvs-cvsupfile

    /src/cvsup/cvs-cvsupfile is the name of the cvsupfile we looked at above. The other parameters to cvsup specify not to use the GUI (-g), and -L2 specifies to produce moderate detail about the actions being performed.

    Getting individual releases

    The example cvsupfile above is useful if you're maintaining a copy of the repository. If you just want to maintain a copy of the sources of one version, say Release 5.0, use the following file instead:

    *default tag=RELENG_5_0_0_RELEASE
    *default release=cvs
    *default host=cvsup9.freebsd.org
    *default base=/usr      for /usr/doc, /usr/ports, /usr/src
    *default prefix=/home/ncvs
    *default delete
    *default use-rel-suffix
    *default compress
    src-all
    

    Be careful with tags. They must exist in the repository, or cvsup will replace what you have with nothing: it will delete all the files. In our original cvsup file, we had two additional sets, ports-all and doc-all. These sets don't have the same release tags, so if you left them in this file, you would lose all the files in the /usr/doc and /usr/ports directory hierarchies.

    Creating the source tree

    If you're tracking the repository, you're not finished yet. Once you have an up-to-date repository, the next step is to create a source tree. By default, the source tree is called /usr/src, though it's very common for /usr/src to be a symbolic link to a source tree on a different file system. You create the tree with cvs.

    Before you check anything out with cvs, you need to know:

  • What do you want to check out? You specify this with a module name, which usually corresponds with a directory name (for example, src). There are a number of top-level modules, including doc, ports, src and www.
  • Which version do you want to check out? By default, you get the latest version, which is FreeBSD-CURRENT. If you want a different version, you need to specify its tag.
  • Possibly, the date of the last update that you want to be included in the checkout. If you specify this date, cvs ignores anymore recent updates. This option is often useful when somebody discovers a recently introduced bug in -CURRENT: you check out the modules as they were before the bug was introduced. You specify the date with the -D option, as we'll see below.
  • Release tags

    FreeBSD identifies releases with two or more numbers separated by periods. Each number represents a progressively smaller increment in the functionality of the release. The first number is the base release of FreeBSD. The number is incremented only when significant functionality is added to the system. The second number represents a less significant, but still important difference in the functionality, and the third number is only used when a significant bug requires rerelease of an otherwise unchanged release. Before Release 3 of FreeBSD, a fourth number was sometimes also used.

    Tags for released versions of FreeBSD follow the release numbers. For release x.y.z you would look for the tag RELENG_x_y_z_RELEASE. For example, to get the current state of the FreeBSD 5.0 source tree, you would look for the tag RELENG_5_0_0_RELEASE.

    Tags for the -STABLE branch are simpler: they just have the release number, for example RELENG_4.The security branch has an additional number, for example RELENG_4_7.

    Some tags diverge from this scheme. In particular, CSRG and bsd_44_lite both refer to the original 4.4BSD sources from Berkeley. If you feel like it, you can extract this source tree as well.

    To find out what tags are available, do:

    # cd $CVSROOT/src
    # rlog Makefile,v | less
    RCS file: /hcme/ncvs/src/Makefile, v
    RCS file: /home/ncvs/src/Makefile, v
    Working file: Makefile
    head: 1.270
    branch:
    locks: strict
    access list:
    symbolic names:
    RELENG_5_0_0_RELEASE: 1.271    5.0 RELEASE
    …
    RELENG_4_7_0_RELEASE: 1.234.2.18    4.7-RELEASE
    RELENG_4_7: 1.234.2.18.0.2    4.7security fixes only
    RELENG_4_7_BP: 1.234.2.18    branch point for 4.7
    RELENG_4_6_2_RELEASE: 1.234.2.12    4.6.2-RELEASE
    RELENG_4_6_1_RELEASE: 1.234.2.12    4.6.1-RELEASE
    RELENG_4_6_0_RELEASE: 1.234.2.12    4.6-RELEASE
    …
    RELENG_4: 1.234.0.2    4-STABLE
    …
    RELEASE_2_0: 1.30    2.0 2.0-RELEASE
    BETA_2_0: 1.30
    ALPHA_2_0: 1.29.0.2
    bsd_44_lite: 1.1.1.14.4BSD-Lite
    CSRG: 1.1.1
    keyword substitution: kv
    total revisions: 179; selected revisions: 179
    description:
    

    This example shows the same file we saw on page 583. This time we use the rlog command, which is part of RCS, to look at the revision log. Normally you'd use cvslog, but that only works in a checked out source tree.

    There are a number of ways to tell cvs the name of its repository: if you already have a CVS subdirectory, it will contain files Root and Repository. The name of the repository is in Root, not in Repository. When you first check out files, you won't have this directory, so you specify it, either with the -d option to cvs or by setting the CVSROOT environment variable. As you can see in the example above, it's convenient to set the environment variable, since you can use it for other purposes as well.

    The repository contains a number of directories, usually one for each collection you track. In our case, we're tracking the source tree and the Ports Collection, so:

  • CVSROOT contains files used by CVS. It is not part of the source tree.
  • ports contains the Ports Collection.
  • src contains the system sources.
  • The directories ports and src correspond to the directories /usr/ports and /usr/src for a particular release. To extract the src tree of the most up-to-date version of FreeBSD-CURRENT, do the following:

    cd /usr
    #cvs co src 2<1 | tee /var/tmp/co.log
    

    To check out any other version, say, everything for Release 4.6, you would enter:

    #cd /usr
    # cvs co -r RELENG_4_6_RELEASE src 2>1 | tee /var/tmp/co.log
    

    If you need to check out an older version, for example if there are problems with the most recent version of -CURRENT, you could enter:

    #cvs co -D "10 December 2002" src/sys
    

    This command checks out the kernel sources as of 10 December 2002. During checkout, cvs creates a subdirectory CVS in each directory. CVS contains four files. We'll look at typical values when checking out the version of the directory /usr/src/usr.bin/du for Release 4.6, from the repository at /home/ncvs:

  • Entries contains a list of the files being maintained in the parent directory, along with their current versions. In our example, it would contain:
    /Makefile/1.4.2.1/Sun Jul 2 10:45:29 2000//TRELENG_4_6_0_RELEASE
    /du.1/1.15.2.7/Thu Aug 16 13:16:47 2001//TRELENG_4_6_0_RELEASE
    /du.c/1.17.2.3/Thu Jul 12 08:46:53 2001//TRELENG_4_6_0_RELEASE
    D
    

    Note that cvs prepends a T to the version name.

  • Repository contains the name of the directory in the repository that corresponds to the current directory. This corresponds to $CVSROOT/directory. In our example, it would contain src/usr.bin/du.
  • Root contains the name of the root of the repository. In our example, it would contain /home/ncvs.
  • Tag contains the version tag of the source tree. This is the RCS tag prefixed by a T. In this case, it is TRELENG_4_6_0_RELEASE.
  • cvs co produces a lot of output—at least one line for each directory, and one line for each file it checks out. Here's part of a typical output:

    Usrc/usr.sbin/mrcuted/rsrr_var.h
    Usrc/usr.sbin/mrouted/vif.c
    Usrc/usr.sbin/mrouted/vif.h
    cvs checkout: Updating src/usr.sbin/mrouted/common
    Usrc/usr.sbin/mrouted/ccmmon/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/map-mbcne
    Usrc/usr.sbin/mrcuted/map-mbcne/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/mrinfc
    Usrc/usr.sbin/mrcuted/mrinfc/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/mrcuted
    Usrc/usr.sbin/mrcuted/mrcuted/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/mtrace
    Usrc/usr.sbin/mrcuted/mtrace/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/testrsrr
    Usrc/usr.sbin/mrcuted/testrsrr/Makefile
    

    The flag at the beginning of the line indicates what action cvs took for the file. The meanings are:

  • U means that cvs updated this file. Either it didn't exist previously, or it was an older version.
  • You won't normally see P on a local update. It implies that cvs patched the file to update it. Otherwise it has the same meaning as U.
  • ? means that cvs found the file in the directory, but it doesn't exist in the repository.
  • M means that cvs found that the file in your working directory has been modified since checkout, but it either didn't need to change it, or it was able to apply the changes cleanly.
  • C found that the file in your working directory has been modified since checkout, and it needed to change it, but it was not able to apply the changes cleanly. You will have to resolve the conflicts manually.
  • After checkout, check the log file for conflicts. For each conflict, you must check the files manually and possibly recover the contents. See the man page cvs(1) for more details.

    Updating an existing tree

    Once you have checked out a tree, the ground rules change a little. Next time you do a checkout, files may also need to be deleted. Apart from that, there isn't much difference between checkout and updating. To update the /usr/src directory after updating the repository, do:

    # cd /usr/src
    # cvs update -Pd
    

    Note that this time we can start in /usr/src: we now have the CVS/ subdirectories in place, so cvs knows what to do without being given any more information.

    Using a remote CVS tree

    A CVS tree takes up a lot of space, and it's getting bigger all the time. If you don't check out very often, you may find it easier to use anonymous CVS, where the tree is on a different system. FreeBSD provides the server anoncvs.FreeBSD.org for this purpose.

    For example, to check out the -CURRENT source tree, perform the following steps:

    $ cd /usr    go to the parent directory
    $ CVSROOT=:pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs    set the server path
    $ cvs login    You only need to do this once
    Logging in to :pserver:anoncvs@anoncvs.freebsd.org:2401/home/ncvs
    CVS password:    enter anoncvs; it doesn't echo
    $ cvs co src
    cvs server: Updating src
    U src/COPYRIGHT
    U src/Makefile
    U src/ Makefile.incl
    (etc)
    
    Страницы:

    FreeBSD is constantly changing. The average time that elapses between changes to the source tree is in the order of a few minutes. Obviously you can't keep up to date with that pace of change.

    In the following three chapters we'll look at how to keep up to date. In this chapter, we'll look at:

  • FreeBSD releases: how the FreeBSD project comes to terms with the rapid rate of change, and how it keeps the system stable despite the changes.
  • How the system sources are stored, and how you can update them.
  • In Chapter 32, Updating the system software, we'll look at how to upgrade FreeBSD to a new release, with particular reference to upgrades to FreeBSD Release 5, and in Chapter 33, Custom kernels, we'll look at building special kernels.

    FreeBSD releases and CVS

    The FreeBSD project keeps the entire operating system sources in a single master source tree, called a repository, which is maintained by the Concurrent Versions System, or CVS. It's included in most multi-CD-ROM distributions of FreeBSD. The repository contains all versions of FreeBSD back to Release 2.0 and the last release from the Computer Sciences Research Group of the University of California at Berkeley, 4.4BSD-Lite, upon which it was based. For copyright reasons FreeBSD Release 1 was not included, because at the time, as the result of the lawsuits described on page 8, it was not permitted to distribute it freely. That situation changed in early 2002, but it's now too late to include FreeBSD Release 1 in the repository.

    CVS is built on top of the Revision Control System, or RCS. RCS keeps multiple versions of files, called revisions, in a single RCS file. Each revision has a number indicating its relationship to the other revisions. The oldest revision has the number 1.1, the next oldest has the number 1.2, and so on. The RCS file contains the most recent revision of the file along with instructions for creating any other revision.

    In addition to this linear sequence, it's possible to update a specific revision in more than one way. The obvious way to update revision 1.2 would create revision 1.3; but it's also possible to create branches, which get numbers like1.2.1.1. Updating revision 1.2.1.1 would create revision 1.2.1.2, and so on. By contrast, the revisions with a two-part number are collectively called the trunk of the tree.

    Symbolic names or tags

    In addition to the numeric identifiers, each of which relates only to a single file, RCS allows you to attach symbolic names to specific revisions. CVS generally calls these names tags, and that's the term you'll see most often. FreeBSD uses tags to indicate the revisions corresponding to a particular release. For example, in the directory /usr/src/sys/kern, revision 1.13 of kern_clock.c, revision 1.12 of kern_fork.c and revision 1.21.4.1 of kern_exec.c participate in RELENG_2_1_0_RELEASE. We'll look at tags in more detail on page 588.

    RCS stores its files either in the same directory as the working fi les it is tracking, or in a subdirectory RCS if it exists. To avoid file name conflicts, RCS appends the characters, v to the RCS file, so the working file main.c would correspond to the RCS file main.c,v. For more details of RCS, see the man page.

    CVS is an extension to RCS that allows concurrent access, making it more suitable for projects involving more than one person. Unlike RCS, it stores its RCS fi les in a separate directory hierarchy, called a repository. Each directory in the working tree contains a subdirectory CVS with information on the location of the repository, the revisions of the working files and a tag if the revision isn't on the trunk.

    If you're a serious developer, there are a number of advantages to keeping a copy of the repository. If you're a casual user, it's probably overkill.

    FreeBSD releases

    There are four main versions of FreeBSD, each intended for use by different people:

    FreeBSD-RELEASE

    FreeBSD-RELEASE is the latest version of FreeBSD that has been released for general use. It contains those new features that are stable, and it has been through extensive testing. You can get it on CD-ROM. FreeBSD-RELEASEs are given a release number that uniquely identifies them, such as 5.0. There are three or four releases a year. A new branch is made for each release of FreeBSD.

    FreeBSD-STABLE

    FreeBSD-STABLE is an updated version of FreeBSD-RELEASE to which all possible bug fixes have been applied, to make it as stable as possible. Fixes are made on a daily basis. It is based on the same source branch as FreeBSD-RELEASE, so it has all the features and fewer bugs. It may contain additional features, but new features are tested in the – CURRENT branch first.

    Due to the frequent updates, FreeBSD-STABLE is not available on CD-ROM.

    Security fix releases

    Despite the name, FreeBSD-STABLE is subject to some problems. Every change to a source tree has the potential to go wrong. In many cases, you're more interested in keeping your system running than you are in getting minor bug fixes. FreeBSD also maintains a second " stable" branch consisting of the release and only very important bug fixes, including security updates. This branch does not have a well-defined name, but it's generally referred to as the security branch.

    FreeBSD-CURRENT

    FreeBSD-CURRENT is the very latest version of FreeBSD, located on the trunk of the tree. All new development work is done on this branch of the tree. FreeBSD-CURRENT is an ever-changing snapshot of the working sources for FreeBSD, including work in progress, experimental changes and transitional mechanisms that may or may not be present in the next official release of the software. Many users compile almost daily from FreeBSD-CURRENT sources, but there are times when the sources are uncompilable, or when the system crashes frequently. The problems are always resolved, but others can take their place. On occasion, keeping up with FreeBSD-CURRENT can be a full-time business. If you use -CURRENT, you should be prepared to spend a lot of time keeping the system running. The following extract from the RCS log file for /usr/src/Makfile should give you a feel for the situation:

    $ cvs log Makefile
    ….
    revision 1.152
    date: 1997/10/06 09:58:11;   author: jkh;   state: Exp;   lines: +41 -13
    Hooboy!
    Did I ever spam this file good with that last commit. Despite 3 
    reviewers, we still managed to revoke the eBones fixes, TCL 8.0 
    support, libvgl and a host of other new things from this file in 
    the process of parallelizing the Makefile. DOH! I think we need 
    more pointy hats - this
    particular incident is worthy of a small children's birthday 
    party's worth of pointy hats. ;-)
    I certainly intend to take more care with the processing of aged 
    diffs in the future, even if it does mean reading through 20K's 
    worth of them. I might also be a bit more anal about asking for 
    more up-to-date changes before looking at them. ;)
    

    This example also shows the list of the symbolic names for this file, and their corresponding revision numbers. There is no symbolic name for -CURRENT, because it is located on the trunk. That's the purpose of the line head, which shows that at the time of this example, the –CURRENT revision of this file was 1.270.

    So why use -CURRENT? The main reasons are:

  • You might be doing development work on some part of the source tree. Keeping "current" is an absolute requirement.
  • You may be an active tester, which implies that you're willing to spend time working through problems to ensure that FreeBSD-CURRENT remains as sane as possible. You may also wish to make topical suggestions on changes and the general direction of FreeBSD.
  • You may just want to keep an eye on things and use the current sources for reference purposes.
  • People occasionally have other reasons for wanting to use FreeBSD-CURRENT. The following are not good reasons:

  • They see it as a way to be the first on the block with great new FreeBSD features. This is not a good reason, because there's no reason to believe that the features will stay, and there is good reason to believe that they will be unstable.
  • They see it as a quick way of getting bug fixes. In fact, it's a way of testing bug fixes. Bug fixes will be retrofitted into the -STABLE branch as soon as they have been properly tested.
  • They see it as the newest officially supported release of FreeBSD. This is incorrect: FreeBSD-CURRENT is not officially supported. The support is provided by the users.
  • If you do decide to use -CURRENT, read the suggestions on page 622.

    Snapshots

    FreeBSD-CURRENT is available in the form of ISO (CD-ROM) images. From time to time, at irregular intervals when the tree is relatively stable, the release team makes a snapshot release from the - CURRENT source tree. They are also available on CD-ROM from some vendors; check the online handbook for details. This is a possible alternative to online updates if you don't want the absolute latest version of the system.

    Getting updates from the Net

    There are a number of possibilities to keep up with the daily modifications to the source tree. The first question is: how much space do you want to invest in keeping the sources? Table 31-1 shows the approximate space required by different parts of the sources. Note that the repository keeps growing faster than the source tree, because it includes all old revisions as well.

    Approximate source tree sizes
    ComponentSize (MB)
    Repository src/sys250
    Repository src1000
    Repository ports300
    Source tree /usr/src/sys110
    Source tree /usr/src450
    Source tree /usr/ports200
    Object/usr/obj160

    The size of /usr/src/sys includes the files involved in a single kernel build. You can remove the entire kernel build directory, but if you want to be able to analyze a panic dump, you should keep the kernel.debug file in the kernel build directory. This changes the size of /usr/src as well, of course. The other object files get built in the directory /usr/obj. Again, you can remove this directory tree entirely if you want, either with the rm command or with make clean. Similarly, the size of /usr/ports includes a few ports. It will, of course, grow extremely large (many gigabytes) if you start porting all available packages.

    If you're maintaining multiple source trees (say, for different versions), you still only need one copy of the repository.

    CVSup

    CVSup is a software package that distributes updates to the repository. You can run the client at regular intervals—for example, with cron (see page 151) to update your repository.

    To get started with CVSup, you need the following:

  • A source tree or repository, which doesn't have to be up to date. This is not absolutely necessary, but the initial setup will be faster if you do it this way.
  • A copy of the cvsup program. Install it with pkg_add from the CD-ROM (/cdrom/packages/Latest/cvsup.tbz).
  • A cvsup file, a command file for cvsup. We'll look at this below.
  • A mirror site from which you can load or update the repository. We'll discuss this below as well.
  • The cvsupfile contains a description of the packages you want to download. You can find all the details in the online handbook, but the following example shows a reasonably normal file:

    *default  release=cvs
    *default  host=cvsup9.freebsd.org
    *default  base=/src/cvsup
    *default  prefix=/home/ncvs
    *default  delete
    *default  use-rel-suffix
    *default  compress
    src-all
    ports-all
    doc-all
    

    The lines starting with *default specify default values; the lines that do not are collections that you want to track. This file answers these implicit questions:

  • Which files do you want to receive? These are the names of the collections in the last three lines: all of the sources, ports and documentation.
  • Which versions of them do you want? By default, you get updates to the repository. If you want a specific version, you can write:
  • *default tag=version
    

    version is a release tag that identifies the version you want, or . (a period) to represent the CURRENTversion. We'll discuss release tags on page 588.

    Alternatively, you might ask for a version as of a specific date. For example:

    *default date=97.09.13.12.2
    

    This would specify that you want the version as it was on 13 September 1997 at 12:20. In this case, version defaults to . (a period).

  • Where do you want to get them from? Two parameters answer this question: host=cvsup9.freebsd.org specifies the name of the host from which to load the files, and release=cvs specifies to use the cvs release. The release option is obsolescent, but it's a good idea to leave it in there until it is officially removed.
  • Where do you want to put them on your own machine? This question is answered by the line *default prefix=/home/ncvs. We're tracking the repository in this example, so this is the name of the repository. If we were tracking a particular release, we would use *default prefix=/usr. The collections are called doc, ports and src, so we refer to the parent directory in each case.
  • Where do you want to put your status files? This question is answered by the line

    *default base=/src/cvsup.
    

    In addition, the file contains three other lines. *default delete means that cvsup may delete files where necessary. Otherwise you run the risk of accumulating obsolete files. *default compress enables compression of the data transmitted, and *default use-rel-suffix specifies how cvsup should handle list files. It's not well-documented, but it's necessary. Don't worry about it.

    Which CVSup server?

    In this example, we've chosen one of the backup US servers, cvsup9.FreeBSD.org. In practice, this may not be the best choice. A large number of servers are spread around the world, and you should choose the one topographically closest to you. This isn't the same thing as being geographically closest—I live in Adelaide, South Australia, and some ISPs in the same city are further away on the Net than many systems in California. Look on the web site http://www.FreeBSD.org for an up-to-date list.

    Running cvsup

    cvsup is a typical candidate for a cron job. I rebuild the -CURRENT tree every morning at 3 am. To do so, I have the following entry in /root/crontab:

    #Get the latest and greatest FreeBSD stuff.
    0 3***./extract-updates
    

    The file /root/extract-updates contains, amongst other things,

    cvsup -g -L2 /src/cvsup/cvs-cvsupfile

    /src/cvsup/cvs-cvsupfile is the name of the cvsupfile we looked at above. The other parameters to cvsup specify not to use the GUI (-g), and -L2 specifies to produce moderate detail about the actions being performed.

    Getting individual releases

    The example cvsupfile above is useful if you're maintaining a copy of the repository. If you just want to maintain a copy of the sources of one version, say Release 5.0, use the following file instead:

    *default tag=RELENG_5_0_0_RELEASE
    *default release=cvs
    *default host=cvsup9.freebsd.org
    *default base=/usr      for /usr/doc, /usr/ports, /usr/src
    *default prefix=/home/ncvs
    *default delete
    *default use-rel-suffix
    *default compress
    src-all
    

    Be careful with tags. They must exist in the repository, or cvsup will replace what you have with nothing: it will delete all the files. In our original cvsup file, we had two additional sets, ports-all and doc-all. These sets don't have the same release tags, so if you left them in this file, you would lose all the files in the /usr/doc and /usr/ports directory hierarchies.

    Creating the source tree

    If you're tracking the repository, you're not finished yet. Once you have an up-to-date repository, the next step is to create a source tree. By default, the source tree is called /usr/src, though it's very common for /usr/src to be a symbolic link to a source tree on a different file system. You create the tree with cvs.

    Before you check anything out with cvs, you need to know:

  • What do you want to check out? You specify this with a module name, which usually corresponds with a directory name (for example, src). There are a number of top-level modules, including doc, ports, src and www.
  • Which version do you want to check out? By default, you get the latest version, which is FreeBSD-CURRENT. If you want a different version, you need to specify its tag.
  • Possibly, the date of the last update that you want to be included in the checkout. If you specify this date, cvs ignores anymore recent updates. This option is often useful when somebody discovers a recently introduced bug in -CURRENT: you check out the modules as they were before the bug was introduced. You specify the date with the -D option, as we'll see below.
  • Release tags

    FreeBSD identifies releases with two or more numbers separated by periods. Each number represents a progressively smaller increment in the functionality of the release. The first number is the base release of FreeBSD. The number is incremented only when significant functionality is added to the system. The second number represents a less significant, but still important difference in the functionality, and the third number is only used when a significant bug requires rerelease of an otherwise unchanged release. Before Release 3 of FreeBSD, a fourth number was sometimes also used.

    Tags for released versions of FreeBSD follow the release numbers. For release x.y.z you would look for the tag RELENG_x_y_z_RELEASE. For example, to get the current state of the FreeBSD 5.0 source tree, you would look for the tag RELENG_5_0_0_RELEASE.

    Tags for the -STABLE branch are simpler: they just have the release number, for example RELENG_4.The security branch has an additional number, for example RELENG_4_7.

    Some tags diverge from this scheme. In particular, CSRG and bsd_44_lite both refer to the original 4.4BSD sources from Berkeley. If you feel like it, you can extract this source tree as well.

    To find out what tags are available, do:

    # cd $CVSROOT/src
    # rlog Makefile,v | less
    RCS file: /hcme/ncvs/src/Makefile, v
    RCS file: /home/ncvs/src/Makefile, v
    Working file: Makefile
    head: 1.270
    branch:
    locks: strict
    access list:
    symbolic names:
    RELENG_5_0_0_RELEASE: 1.271    5.0 RELEASE
    …
    RELENG_4_7_0_RELEASE: 1.234.2.18    4.7-RELEASE
    RELENG_4_7: 1.234.2.18.0.2    4.7security fixes only
    RELENG_4_7_BP: 1.234.2.18    branch point for 4.7
    RELENG_4_6_2_RELEASE: 1.234.2.12    4.6.2-RELEASE
    RELENG_4_6_1_RELEASE: 1.234.2.12    4.6.1-RELEASE
    RELENG_4_6_0_RELEASE: 1.234.2.12    4.6-RELEASE
    …
    RELENG_4: 1.234.0.2    4-STABLE
    …
    RELEASE_2_0: 1.30    2.0 2.0-RELEASE
    BETA_2_0: 1.30
    ALPHA_2_0: 1.29.0.2
    bsd_44_lite: 1.1.1.14.4BSD-Lite
    CSRG: 1.1.1
    keyword substitution: kv
    total revisions: 179; selected revisions: 179
    description:
    

    This example shows the same file we saw on page 583. This time we use the rlog command, which is part of RCS, to look at the revision log. Normally you'd use cvslog, but that only works in a checked out source tree.

    There are a number of ways to tell cvs the name of its repository: if you already have a CVS subdirectory, it will contain files Root and Repository. The name of the repository is in Root, not in Repository. When you first check out files, you won't have this directory, so you specify it, either with the -d option to cvs or by setting the CVSROOT environment variable. As you can see in the example above, it's convenient to set the environment variable, since you can use it for other purposes as well.

    The repository contains a number of directories, usually one for each collection you track. In our case, we're tracking the source tree and the Ports Collection, so:

  • CVSROOT contains files used by CVS. It is not part of the source tree.
  • ports contains the Ports Collection.
  • src contains the system sources.
  • The directories ports and src correspond to the directories /usr/ports and /usr/src for a particular release. To extract the src tree of the most up-to-date version of FreeBSD-CURRENT, do the following:

    cd /usr
    #cvs co src 2<1 | tee /var/tmp/co.log
    

    To check out any other version, say, everything for Release 4.6, you would enter:

    #cd /usr
    # cvs co -r RELENG_4_6_RELEASE src 2>1 | tee /var/tmp/co.log
    

    If you need to check out an older version, for example if there are problems with the most recent version of -CURRENT, you could enter:

    #cvs co -D "10 December 2002" src/sys
    

    This command checks out the kernel sources as of 10 December 2002. During checkout, cvs creates a subdirectory CVS in each directory. CVS contains four files. We'll look at typical values when checking out the version of the directory /usr/src/usr.bin/du for Release 4.6, from the repository at /home/ncvs:

  • Entries contains a list of the files being maintained in the parent directory, along with their current versions. In our example, it would contain:
    /Makefile/1.4.2.1/Sun Jul 2 10:45:29 2000//TRELENG_4_6_0_RELEASE
    /du.1/1.15.2.7/Thu Aug 16 13:16:47 2001//TRELENG_4_6_0_RELEASE
    /du.c/1.17.2.3/Thu Jul 12 08:46:53 2001//TRELENG_4_6_0_RELEASE
    D
    

    Note that cvs prepends a T to the version name.

  • Repository contains the name of the directory in the repository that corresponds to the current directory. This corresponds to $CVSROOT/directory. In our example, it would contain src/usr.bin/du.
  • Root contains the name of the root of the repository. In our example, it would contain /home/ncvs.
  • Tag contains the version tag of the source tree. This is the RCS tag prefixed by a T. In this case, it is TRELENG_4_6_0_RELEASE.
  • cvs co produces a lot of output—at least one line for each directory, and one line for each file it checks out. Here's part of a typical output:

    Usrc/usr.sbin/mrcuted/rsrr_var.h
    Usrc/usr.sbin/mrouted/vif.c
    Usrc/usr.sbin/mrouted/vif.h
    cvs checkout: Updating src/usr.sbin/mrouted/common
    Usrc/usr.sbin/mrouted/ccmmon/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/map-mbcne
    Usrc/usr.sbin/mrcuted/map-mbcne/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/mrinfc
    Usrc/usr.sbin/mrcuted/mrinfc/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/mrcuted
    Usrc/usr.sbin/mrcuted/mrcuted/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/mtrace
    Usrc/usr.sbin/mrcuted/mtrace/Makefile
    cvs checkout: Updating src/usr.sbin/mrcuted/testrsrr
    Usrc/usr.sbin/mrcuted/testrsrr/Makefile
    

    The flag at the beginning of the line indicates what action cvs took for the file. The meanings are:

  • U means that cvs updated this file. Either it didn't exist previously, or it was an older version.
  • You won't normally see P on a local update. It implies that cvs patched the file to update it. Otherwise it has the same meaning as U.
  • ? means that cvs found the file in the directory, but it doesn't exist in the repository.
  • M means that cvs found that the file in your working directory has been modified since checkout, but it either didn't need to change it, or it was able to apply the changes cleanly.
  • C found that the file in your working directory has been modified since checkout, and it needed to change it, but it was not able to apply the changes cleanly. You will have to resolve the conflicts manually.
  • After checkout, check the log file for conflicts. For each conflict, you must check the files manually and possibly recover the contents. See the man page cvs(1) for more details.

    Updating an existing tree

    Once you have checked out a tree, the ground rules change a little. Next time you do a checkout, files may also need to be deleted. Apart from that, there isn't much difference between checkout and updating. To update the /usr/src directory after updating the repository, do:

    # cd /usr/src
    # cvs update -Pd
    

    Note that this time we can start in /usr/src: we now have the CVS/ subdirectories in place, so cvs knows what to do without being given any more information.

    Using a remote CVS tree

    A CVS tree takes up a lot of space, and it's getting bigger all the time. If you don't check out very often, you may find it easier to use anonymous CVS, where the tree is on a different system. FreeBSD provides the server anoncvs.FreeBSD.org for this purpose.

    For example, to check out the -CURRENT source tree, perform the following steps:

    $ cd /usr    go to the parent directory
    $ CVSROOT=:pserver:anoncvs@anoncvs.FreeBSD.org:/home/ncvs    set the server path
    $ cvs login    You only need to do this once
    Logging in to :pserver:anoncvs@anoncvs.freebsd.org:2401/home/ncvs
    CVS password:    enter anoncvs; it doesn't echo
    $ cvs co src
    cvs server: Updating src
    U src/COPYRIGHT
    U src/Makefile
    U src/ Makefile.incl
    (etc)
    
    Вернуться к учебному плану