A more tenuously package-related question

[Clifton Royston]

On Sun, Oct 14, 2007 at 01:19:17PM -1000, Clifton Royston wrote:
> On Sun, Oct 14, 2007 at 04:05:20PM -0700, soralx at cydem.org wrote:
> > >   I used to use pkg_update from the 'pkg_install-devel' toolset to
> > > upgrade systems via replacement of binary packages.  ... 
> > >   Is there any better equivalent tool at the moment, or should I just
> > > resuscitate the old "pkg_update"?
> > 
> > Did you try ports-mgmt/portupgrade? You can run it as `portupgrade -P`
> > for binary updates. Besides actual 'portupgrade', it has a set of
> > useful tools, too. But be warned -- the utility is snail-slow.
> 
>   I did look at it, but it appeared that it needed to run off the
> FreeBSD ports tree, whereas I'm building packages from a separate
> instance of the ports tree in our own CVS, with local modifications,
> and then deploying these packages on multiple servers.  (This time
> around, I'm planning to not even install the ports tree on servers
> other than the build server.)  I therefore need to use a utility which
> can operate using only the dependency information in the pkgdb and
> embedded in the package files themselves.
> 
>   After posting before, I decided to explore pkg_replace, and it
> appears that it might be able to do what I want with the right options.

  I got a request to summarize my results to the list, so here's a
quick write-up.  Based on my preliminary testing last week, pkg_replace
looks like the right tool for package-based server maintenance.

  One invaluable feature which was not immediately obvious from the
description and man page is that if you give it a list of binary
packages on the command line, it orders the updates correctly based on
the dependencies between those packages.

  Thus updating my test server with the recently security-fixed
versions of the packages for png and ImageMagick was just a matter of
executing:
  sudo pkg_replace png-1.2.22.tbz ImageMagick-nox11-6.3.5.10_1.tbz 
in my package repository directory.

  Updating all of my locally written software packages from 1.99 to
2.00 was as simple as:
  sudo pkg_replace *-2.00.tbz

Given this command line, pkg_replace ordered the dependencies properly,
and then pkg_deleted each old package and replaced it with the updated
version in correct dependency order, and fixed the requirements and
dependency links in the package DB.  This is much better than
pkg_update could do in my experience; if you tried to pkg_update a
package in which the newer version had a dependency which had not yet
been satisfied, it would simply fail with the old version deleted and
the new one not yet installed.  (I have not yet checked how pkg_replace
works if you are replacing a package with a newer version which has
additional dependencies not present in the old one, so I don't know
whether it will invoke pkg_add to recursively add the new requirements,
but as long as all the packages you want to replace are in one command
line it appears to DTRT.)

  I've confirmed you can also

  sudo pkg_replace -f foo-1.2.3.tbz

  to force version 1.2.3 of foo to replace some version x.y.z >= 1.2.3. 
Without the -f it will balk at replacing a package which has the same
or higher version # than the one you're installing.  (I had a interim
version of a package where I had omitted an item from its packing list,
and so wanted to replace it without revving the version.)  All good
behavior IMHO.

  Another interesting feature is that its default behavior is to use
pkg_create to backup the package you're replacing, according to its
packing list, before deleting it.  This means by default you should
find it trivially easy to roll back the change you just made.

  It would be really nice to have a tool with this capability in the
base system some day (I'm just saying...)
  -- Clifton 

-- 
    Clifton Royston  --  cliftonr at iandicomputing.com / cliftonr at lava.net
       President  - I and I Computing * http://www.iandicomputing.com/
 Custom programming, network design, systems and network consulting services