Very Beginning CVSup Questions

[Giorgos Keramidas]

On Mon, 21 Jul 2008 20:08:37 -0400, "J.C." <human2205 at gmail.com> wrote:
> I'm a beginner with FreeBSD and somewhat intermediate with Unix-like
> operating systems in general, so please bear the nature of my
> questions. I have some questions about CVSup that seem unclear from
> the handbook. Right now I'm sticking with RELENG_7_0; I intend to
> track -STABLE once I get the hang of CVSup, make buildworld, etc.
>
> I understand that the supfile contains the list of *default settings
> (*default tag=RELENG_7_0 etc.) followed by the list of "collections".
> The "Using CVSup" page suggests simply using the src-all collection. I
> understand that when tracking -STABLE I want to update the ports
> collection before running make buildworld;

Not necessarily.  If you are tracking a -STABLE branch, the rule is that
"ports compiled on earlier builds should work in later builds".  There
are very few exceptions that may require a rebuild of ports, but the
FreeBSD team tries to avoid those if at all possible.

> is the ports collection included in the "base source tree" (i.e. does
> src-all imply ports-all) or should ports-all be included as a separate
> line beneath src-all?

It's probably a good idea to use a separate `supfile' for src/ and
ports/.  There are a few tiny but important differences between the
"base system" (the src-all collection) and the ports.

One of the differences is that the base system is "branched".  This
means that the branch name "RELENG_7" carries an important and well
defined meaning for "src-all".  There are no branches in ports, on the
other hand.

A consequence of this is that using the same supfile with the option
"*default tag=RELENG_7_0" may do moderately surprising to your ports
tree, like deleting it altogether.  When CVSup fails to find a
particular collection in the tag/branch you asked, and the supfile has
enabled the "*default delete use-rel-suffix" option too, it _deletes_
the files that don't exist on the requested tag/branch.

To avoid surprises like these, you can use two supfiles: one for the
"src-all" collection, and one for the "ports-all" collection.

> The "Using the Ports Collection" page in the handbook says to make
> sure /usr/ports is empty before running csup because otherwise "csup
> will not prune removed patch files." Isn't this what the "delete" in
> the supfile (as in the line *default release=cvs delete use-rel-suffix
> compress) is for? Do I have to clean /usr/ports every time I run csup
> or just the first time?

Probably not.  It's been a while that I haven't used CVSup for ports/,
so someone with more recent experience should answer this.

> If I don't care about encrypted transmission or HTTP vs. CVS
> protocols, are there any compelling reasons to use portsnap instead of
> CVSup/csup?

Speed.  Portsnap doesn't have to worry about tags, branches, and CVS
file revisions in the common case, so it can usually finish before CVSup
has even finished uploading the current file versions.

I just updated my /usr/ports tree with portsnap, and it took all of 50
seconds to fetch and apply 169 patches:

| root at kobe:/root# \time portsnap fetch update
| Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
| Fetching snapshot tag from portsnap1.FreeBSD.org... done.
| Fetching snapshot metadata... done.
| Updating from Sat Jul 19 18:10:14 EEST 2008 to Tue Jul 22 03:17:39 EEST 2008.
| Fetching 3 metadata patches.. done.
| Applying metadata patches... done.
| Fetching 0 metadata files... done.
| Fetching 169 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160.... done.
| Applying patches... done.
| Fetching 22 new ports or files... done.
| Removing old files and directories... done.
| Extracting new files:
| [lots of file paths snipped]
| /usr/ports/x11/xloadimage/
| Building new INDEX files... done.
|        68.64 real        12.99 user        24.40 sys
| root at kobe:/root#

That's fast enough for me :-)

Having said that, there are compelling reasons to use CVSup for ports if
you are a developer who wants to make local patches for some of the
ports, or if you are maintaining a large number of ports.  In this case,
having a local CVS mirror of the ports, and checking out from CVS may be
useful, because you can see the history of the ports, browse through
patches committed, look at port changelogs, or even maintain a locally
patched /usr/ports tree in semi-offline mode.

That mode of updating is useful too.  It all depends on what you are
planning to do with your /usr/ports tree.