Utility for safe updating of ports in base system

[David Wolfskill]

On Thu, Mar 20, 2008 at 01:05:27AM -0700, Doug Barton wrote:
> ...
> >One of the
> >requirements of an upgrade system is predictability, this can only
> >be achieved by using binary packages.
> 
> You gain a certain amount of flexibility with packages, at the expense of 
> being able to customize things. As long as the user understands that, then 
> it's fine.
>...

With respect, that (the notion that use of packages inherently
reduces flexibility) doesn't quite follow, from my perspective:  it
depends on who makes the packages.  (What follows is unlikely new to
Doug, as I touched on it a while back in a private exchange; I thought
it might be of use or interest to the list, though.)

My preferred MO is to build from sources, but within a given set
of related machines (of sufficiently similar architectures), avoid
doing the builds themselves on "production" machines:  I have a
machine set up to do FreeBSD builds, for example, and install
FreeBSD, built on that system, onto other system(s) here at home.

That is why the output of "uname -a" on my firewall machine ("janus")
shows that the kernel was actually built on a machine named "freebeast":

janus(6.3-S)[1] uname -a
FreeBSD janus.catwhisker.org 6.3-STABLE FreeBSD 6.3-STABLE #24: Sun Mar  2 07:13:33 PST 2008     root at freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/JANUS  i386
janus(6.3-S)[2] 

I would prefer to do something similar for ports:  build my own
packages on that machine, then be able to use my preferred port
management tool to run through the list of installed ports on (say)
my firewall box, and have it fetch the packages from my local machine
(or effectively *on* the machine being updated, as my build machine
exports certain file systems to facilitate installation on other
local machines).  (And this is, in fact, how I had things set up
when I used a different port management program.)

This also allows me to have built a package on the non-production
"build machine," test it, and after I'm satisfied that the package
is likely to work in my environment, upgrade the port on a somewhat
more "sensitive" machine (e.g., the one my spouse uses for email &
Web browsing).

And there are some ports -- OpenOffice and Firefox come to mind --
where building a given version more than once veers into the
"masochistic" classification (IMO).  (And in the case of OpenOffice, in
particular, the port might feasibly be installed and used on a system
that doesn't really have the resources to build it.)

Thus, for me, being able to customize by building my own packages,
then using those custom-built packages for upgrading other systems
is a useful approach.  While in theory, I could do this manually
(roughly: run the port management tool with a -n flag so it won't
actually change anything, but would report what warrants updating,
then, for each port that has an available update, force a pkg_delete,
then do a pkg_add using the updated port's package), that's a lot of
clerical work to do by hand -- and to me, that's just about synonymous
with "error-prone."  So having my preferred port management tool be able
to perfom upgrades using packages would be useful for me.

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
I submit that "conspiracy" would be an appropriate collective noun for cats.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20080320/34a367aa/attachment.pgp