[wplug-bsd] /usr/ports maintenance mechanisms

[Bill Moran]

Daryl_Clevenger at cs.cmu.edu wrote:

<snip>

>>>If I do not want to build from source, what method should I use to
>>>update the "usr.bin" (?) package and other core components for FreeBSD?
>>
>>If you are tracking usr.bin then you are trying to rebuild the base system no
>>t 
>>the packages. If you don't want to rebuild your base system from source the 
>>the recommended way would be to wait for the need release and download it.
>>If your tracking usr.bin then you should read about "Building World" and 
>>"Keeping Current" on the FreeBSD site in the Handbook.
> 
> Not necessarily what I wanted to hear, but understandable.  If I need
> a new version of /sbin/dump, I would need to download the source,
> updates and/or patches and following the appropriate build instructions.

Two points here:
1) updating "world" via cvsup and make is not terribly complicated.  If you've
ever built a kernel on Linux, it's considerably easier (in my opinion)
2) Programs that people often want to maintain seperatly from the base
distribution usually have a port as well (perl is a prime example)  This allows
the FreeBSD team to be careful and conservative about what is distributed in
the base system, while still allowing users to install bleeding-edge software.

> I actually did not see anything about "Keeping Current" at
> 
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html
> 
> I found section 21.3 "Synchronizing Your Source" and it makes sense.

That's the right part of the handbook.  Section 21.2.1 is what I think
he's referring to (these sections explain the different release tracks
for FreeBSD in an attempt to help the user understand which one he/she
needs to use)

>>>Finally, do I simply need to be more patient and expect portupgrade to
>>>find newer versions of packages infrequently?  I have had a 4.9 system
>>>since Jan 2004 (one, then replaced with another and a clean install).
>>>Everything pkg_add -r installs seems to be the same age as the 4.9
>>>distribution.  Is a distribution with its /usr/ports frozen at the
>>>time it is created?

I believe the packages are snapshotted to match 4.9-RELEASE, and then pkg_add
only grabs the versions that match the snapshot.

Packages are not built as often as ports are updated.  As a result, you can't
always get the latest in package form.  I also believe (not sure) that
portupgrade uses the /usr/ports tree as a database to find what should be
available.  As a result, even if there is a new package available, if you
haven't cvsupped your ports, portupgrade won't know about it.

>>>In summary, how should I maintain /usr/ports and other parts of the
>>>system when I do not want or need to run make?

You're running 4.9, which means the base system should be tracked to RELENG_4_9.
This is a bugtracking branch that only gets changes that fix major bugs and
security problems.  RELENG_4_9 isn't as well documented as are -STABLE and
-CURRENT, but you can follow the same instructions for updating to -STABLE,
just substitute RELENG_4_9 for RELENG_4 in your cvs tag.  Then follow the
instructions for making world/kernel.  Note that you only need to do this
when a change is announced to the RELENG_4_9 branch (i.e. when a security
problem is found) and that's infrequent.  I recommend subscribing to
freebsd-security-notifications (very low volume mailing list ... the only thing
on it is official security announcements) so you know when to upgrade.

Keeping ports updated is a little more complicated.  Here's the _best_ method,
though certainly not the easiest.  Monitor which ports you are using, when you
see new versions that you want/need, cvsup your ports and check the Makefile
for the port you want to upgrade.  The PORTVERSION= line will tell you what
version is currently in the port, if it's the version you want, run
portupgrade -PR <portname>  This will cause the port to be upgraded (first
from a package, then compiling from source if a package is not available)
as well as any ports that the port requires (the -R does that).  With big
ports that take a lot of dependencies, this can take a while, so start it
before you got to bed.  I suppose you could use -PPR, but I figure if I'm
upgrading the port, I'm upgrading, period.

> Reading the handbook section "Synchronizing Your Source", I created
> a "ports-supfile" from the example file.
> 
> If I were to run "cvsup" to update /usr/ports, then would
> 
> portupgrade -PP mozilla-firebird
> 
> remotely fetch an updated precompiled package for mozilla-firebird?
> The man page for portupgrade implies that this is what would happen,
> but before I cvsup /usr/ports I want to know if this is true.

Yes, you've got the right idea.  I recommend a _slightly_ different
approach, but what you're suggesting would work just fine.

>>a different story. I'm running 5.2.1 and I have had to update a port in about
>> 
>>2 months. I've been using FreeBSD since 3.3 and from experience you don't 
>>really need to update all that much.
> 
> I tried a 5.2 install on an old 133MHz machine, but sysinstall got
> a SEGV.  A 4.9 install was smooth and the system was useable running
> X.  I now have a faster machine and decide to just go with 4.9.

If you're new, you're better off with 4.9 anyway.  I think support for
older hardware is starting to wane in the 5 branch, but since it's still
beta, it's hard to say for sure.

>>Now if you thinking about security patches for the kernal and base system the
>>n 
>>you want to talk about track "src" or "sys" not the "ports"
> 
> Yes, this helped very much.  I just need to develop a good understanding
> of the maintenance and release model for the base system and /usr/ports
> so that I can determine a sensible maintenance method for my systems.

The model isn't all that complicated, although it's a bit extensive.
First -CURRENT is where all new development takes place.  -CURRENT is where
new 5.X versions are being developed.
5.X-RELEASE is a relatively stable snapshot of -CURRENT.  The 5.X releases
are of beta quality at this time, although FreeBSD's concept of beta is
pretty damn stable
-STABLE is where new features are tested before addition to 4.X.  Generally,
something new is added to -CURRENT.  After considerably testing, it's added
to -STABLE.  This is not always the case, because some new features from
-CURRENT won't work in -STABLE and vice-versa.
4.X-RELEASE is a stable snapshot of -STABLE.  There is a lengthy testing
process that is done to ensure that each 4.X release is as stable as possible,
so the latest 4.X release is the best one to be running.
4.9 security branch (identified by a RELENG_4_9 cvs tag) is for security
fixes to 4.9-RELEASE.  You can get these fixes other ways as well (as patches,
for example)  Good practice is to monitor the security mailings from FreeBSD
and upgrade to RELENG_4_9 each time a problem is announced.  I'm even lazier
than that, however, as I'll research the nature of the security problem to
see if it even applies to me before upgrading.  As a result, I generally only
need to upgrade about every third security announcement.  Which ends up being
ever 4-6 months on average.

The ports tree is maintained slightly differently, there is no real -RELEASE
or -STABLE for ports, just -CURRENT, and both FreeBSD-CURRENT and
FreeBSD-STABLE use the same ports tree (if you dig into the nitty-gritty,
you'll find that a lot of ports detect the version of FreeBSD they're being
run on and adjust the config as appropriate)
The ports tree is almost a seperate project from the rest of FreeBSD, there's
even an effort to make the ports work on Linux, to consolidate the development
effort.

-- 
Bill Moran
Potential Technologies
http://www.potentialtech.com