Same version on binary packages and updated ports
freebsd at edvax.de
Fri Dec 30 13:31:19 UTC 2011
On Fri, 30 Dec 2011 13:14:35 +0000, RW wrote:
> On Thu, 29 Dec 2011 19:53:25 +0100
> Walter Alejandro Iglesias wrote:
> > I really appreciate that you all, Jerry, Polytropon and Chuck,
> > took your time to answer me. But I think some of you understood
> > paragraphs like individual-separated statements, that's why you
> > did not fully understand my question (my horrible English helps
> > too :-)).
> > Let's see if I can explain myself.
> > I know that FreeBSD base system and 3rd party are "managed"
> > separately. For RELEASE I meant the ports included in a fresh
> > RELEASE install. The scenario is: what to do after a fresh
> > RELEASE install. Once you updated the ports with 'portsnap fech
> > extract update' you have newer versions at the port tree. Then
> > you can upgrade the already installed software using
> > portupgrade... But compiling!
> One strategy is to use csup to only update the port tree to release
> tags and so use successive release packages as you update the base
> system. You need to check portaudit for vulnerabilities.
For such tasks, csup provides a good basis for explicitely
specifying a RELEASE or security patch level. This can be
applied to both the sources and the ports tree (of the
> An alternative is to use stable packages. There are two problems with
> this. The first is that whilst these packages will mostly work they are
> not guaranteed to be compatible with release, or older stable, base
> systems. You can eliminate this entirely by using stable and updating
> world after updating the ports tree.
A common rule is: If you use -STABLE for the OS, you
want to keep your ports tree current and do security
upgrades whenever neccessary (see portaudit for that
functionality), or if the users of the production
server require a certain version change. Using the
ports infrastructure can also be helpful when you
need to so something "extraordinary", like intendely
installing an older port (see portdowngrade for this
particular task) or fixing a port change from today
to tomorrow (as this will show up in a csup delta,
but not neccessarily as fast in a portsnap run).
> The second problem is the variable lag between a port being
> updated and the package becoming available. Frequent updating
> exacerbates this problem. If you use portupgrade -P every day it will
> probably never use a package file.
In this case, I would also suggest using the compiling
approach. Binary packages don't give you the flexibility
to follow -STABLE or -RELEASE-p<level> that closely in
> If it's for a production server, you might consider building your own
> packages on a separate machine.
You could also designate a jail for the building process
(if the server has enough power) and either use the
results generated in that jail for installation or
follow the suggestion of using the packages generated
in that jail (/usr/ports/packages will be populated
by the "make package" command).
However, as you're mentioning a _production_ server,
it's always wise to test the updated software before
bringing it into operation for that system. The idea
of using a "mirrored server" for testing comes handy
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...
More information about the freebsd-questions