Richard,

    Thanks for the information.  I'm going to try it out this week.  I
like the idea
of a meta-package to track the installed packegs on the system.

    I am quiet aware of the build from src nature of pkgsrc.  I don't mind =
going
down that route as a lot of the Sparc64 needs to be re-built from src, as p=
er my
expereince.



chers,

    mehul


On 8/2/05, Richard Rauch <rkr@olib.org> wrote:
> Some people have advocated using pkg_check to update packages.  I
> haven't looked into it, yet.
>=20
> "make update" has problems, which you will probably hear about (and
> certainly you can find out about if you dig a little in the list
> archives...(^&).  Despite the problems, I use "make update".
>=20
> I'm not familiar with the Debian "apt-get upgrade", but from my
> previous Debian experience, one big change I'll point out (which
> may be obvious) is that pkgsrc is a *source* package system, so
> updates go through a build process with attendent issues.  (There
> also are binary packages built from pkgsrc.  I haven't used them
> much in years and don't know if there's anything comparable for
> pkgsrc binary packages.)
>=20
>=20
> Here's how to use "make update", but please read to the end for
> caveats:
>=20
> First, you need to update pkgsrc itself.  E.g., if you have it
> set up to track via CVS, you can:
>=20
>   (cd /usr/pkgsrc && cvs update -PAd)
>=20
> If you want to update, e.g., the GIMP, you would type:
>=20
>   (cd /usr/pkgsrc/graphics/gimp && make update)
>=20
> ...assuming that you have installed pkgsrc in the usual /usr/pkgsrc
> location.
>=20
>=20
> What pkgsrc will do for "make update" is something like this, as I
> understand it, in the particular case of the GIMP:
>=20
>   It will remove anything that depends upon the GIMP.
>=20
>   It will remove the GIMP.
>=20
>   It will look at the things that the GIMP depends upon, and if the
>   GIMP requires that any of them be updated, those packages will be
>   updated.
>=20
>   It will then rebuild and reinstall the GIMP.
>=20
>   It will then rebuild and reinstall anything that you had previously
>   installed which depended upon the GIMP.  (Conceivably updating
>   things that the current versions of thsoe packages want to have
>   updated.)
>=20
> If all goes well, then updating a single package, such as the GIMP,
> can conceivably update many packages, owing to interdependencies of
> shared libraries.
>=20
>=20
> CAVEATS:
>=20
> The general caveat is summed up in the "If all goes well," prefix,
> above.  (^&
>=20
> 1) pkgsrc deinstalls before building and reinstalling.  So during the
> update process, the package is unavailable.
>=20
> 2) If pkgsrc fails to build the package for some reason, then the old
> package will not automatically be installed---you'll just be left with
> an uninstalled package and a partial build.
>=20
> 3) Both of the above points apply to any other packages that are inci-
> dentally updated by pkgsrc.
>=20
> 4) If pkgsrc fails to update a package that the GIMP "requires" to be
> updated, then that will also stop rebuilding the GIMP (and perhaps
> other packages).
>=20
> 5) If you feel like taking a chance, you can use "make replace" to
> selectively update dependencies.  "make replace" doesn't have as
> much (any?) web-of-dependencies impacts, so you can use "make replace"
> to avoid the massive rebuilds that "make update" can induce.  The
> danger is that some shared libraries change ABIs in ways that they
> shouldn't, and you run a non-zero risk of having silently broken
> applications if you use "make replace".
>=20
> 6) To protect against potential lossage with "make update", there
> are some ideas to use:
>=20
>  * Use "pkg_info" to generate a list of all of your installed
>    packages so that you know what you had/have.
>=20
>  * Create binary packages so that you can readily revert if things
>    crash.  Use "make package" on the package directories, or
>    "pkg_tarup" after-the-fact.
>=20
>  * Create a so-called meta-pkg that has dependencies of all of
>    your desired packages so that it can be used to try to generate
>    all of the packages that you care about.
>=20
>  * Use either a chroot environment or a spare machine to test that
>    an update will go smoothely (and, then, just go ahead and
>    make binary packages while you're at it...(^&) so that your
>    "production" machine(s) don't have downtime.
>=20
>    Rebooting a single computer from a different disk or
>    partition is a (dollar-wise) cheap way to have a second system,
>    if you don't need your "main" system to be up 100% of the time.
>=20
>  * pkgsrc has for some time (I don't know how long; I only
>    learned this a few days ago) been maintaining the quarterly
>    branches.  The quarterly branches are more stable and should
>    build with fewer problems.  If you don't need to track the
>    CVS HEAD of pkgsrc, then consider following just the the
>    most recent quarterly branch for security fixes.
>=20
>=20
> --
>   "I probably don't know what I'm talking about."  http://www.olib.org/~r=
kr/
>=20


--=20
Mehul N. Sanghvi
email: mehul.sanghvi@gmail.com