[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: How to upgrade?
> > I tried to use pkgsrc-2008Q1 on Solaris 10 and now I want to upgrade
> > it to 2008Q2. Which is the official way to do this? I couldn't not
> > find something about it in the docs.
> There are several approaches. First, install pkgtools/pkg_chk and read
> and understand the man page. Assuming you are building from source,
> update to the new branch. Then one of the following.
> Use pkg_chk to make a list of packages you have installed (pkg_chk -g)
> Trim the list down to what you actually want.
> Delete all of them.
> pkg_chk -ask -C my-pkgchk.conf
> alternatively, add binary packages
> [This approach works well, but there's a period when you have no packages.]
> 'make update' on packages that are out of date. This will remove and
> rebuild depending packages. [I do not recommend this because it can
> fail partway through and then it's awkward to recover.]
> Use pkgtools/pkg_rolling-replace, running it as 'pkg_rolling-replace
> -uv'. See the man page and ask if you have questions. This does
> 'make replace' one package at a time, in topologicallly sorted order
> by dependencies, and keeps track of which need rebuilding. [I
> recommend this, but I designed pkg_rr to do what I want, so my
> recommendation should be taken with come caution.]
One method you overlooked to mention is to use pkgtools/lintpkgsrc and
pkgtools/pkgdepgraph to compute which packages and the order in which
packages should be deleted and built/added so as to minimize the
number of "double builds" which are all too common in an otherwise
unmanaged "make update" process. This (or a variant of it) is the
method I've landed on as being my personal preference after previously
using "make update".
The method goes something like this:
cvs update -A -P -r <whatever> # update your pkgsrc source
lintpkgsrc -i > pkgdepgraph.in # compared installed pkgs to source
audit-packages >> pkgdepgraph.in # add in vulnerable packages
pkgdepgraph -D pkgdepgraph.in > delete_order # compute proper order
pkgdepgraph -R pkgdepgraph.in > rebuild.sh # compute rebuild script
pkg_delete `cat delete_order` # remove out-of-date or insecure pkgs
sh # to let env setting be "temporary"
export ALLOW_VULNERABLE_PACKAGES=yes # don't fail on still-vulnerable pkgs
sh rebuild.sh # install updated packages
This method does not handle package renames at all (e.g. gnome-vfs2 to
gnome-vfs), so the rebuild step may have to be repeated after editing
of the rebuild.sh script.
The ALLOW_VULNERABLE_PACKAGES=yes setting is of course a matter of
local policy. If you don't set it, and encounter the need to install
a package which is still registered as vulnerable in some way
(irrespective of its severity), the rebuild.sh script will stop and
require manual attention, and the period when you're without your
packages will be prolonged. It's always a good idea to inspect the
output of audit-packages after such an upgrade to see if any of the
currently installed packages might warrant a de-installation.
The above can also trivially be modified to deal with binary packages,
via "pkgdepgraph -R -A ...", but that then presumes you already have a
binary package repository to upgrade from, and that it's approximately
of the same vintage as your newly updated pkgsrc tree. This is
however a good way to minimize the time you are without your packages.
If there was a simple way to fetch the new binary packages to a local
directory, that would further minimize the amount of "downtime" for
the package insallation.
Additionally, you might want to use pkgtools/pkg_tarup to bundle up
and tuck away your old binary packages before you delete them -- they
might come in handy if a package you need has been removed, or is not
available in a newer version after all (could be due to build errors
or whatnot), or there is some local package you had installed but
which isn't available in binary form from your binary package
Main Index |
Thread Index |