Re: pkg_comp HOWTO (Was: pkgsrc)

["S.P.Zeidler" <spz%serpens.de@localhost>]

rhialto%falu.nl@localhost (Rhialto) writes:

>- Outside pkg_comp: now comes the critical part.
>  Have a backup first.

>  - Carefully upgrade important services such as sendmail + spamassassin +
>    spamass-milter + milter-greylist, bind9 (named9), siproxd, sudo, pkg_chk.
>    If an easy upgrade isn't possible due to dependencies (Perl), just stop
>    the service.
>    Keep a root shell running just in case sudo stops working.

>  - export PACKAGES=/scratch/packages.amd64-4.0/All

>  - (nonroot) pkg_chk -lb      double-check all binary packages are present

>  - pkg_chk -rv                remove outdated packages
>    pkg_chk -akbv      add, keep going, use binaries only.     
>  or
>  - pkg_chk -ukbv      update, use binaries only, keep going.

>    This should be able to use only binaries as generated before.

There's a different approach, assuming that your build host is not
neccessarily the host that needs updating (and has no pkgsrc tree),
and IMO better for spot updates for packages with lots of dependents:

on the host that needs updating, do:
export PKG_PATH=where-the-tgz-are
audit-packages > pkgdepgraph.in
pkgdepgraph -D pkgdepgraph.in > pkgdepgraph.delete
pkgdepgraph -R -A pkgdepgraph.in > pkgdepgraph.new

change pkgdepgraph.new so you install the new versions, not the ones you
are deleting, then:
pkg_delete `cat pkgdepgraph.delete` && sh pkgdepgraph.new

- upgrade configs if necessary

>- Restart any services stopped before.

Automating the first part of the recipy is fairly easy; if there is a
repository with binary packages for your OS-version/arch available and
your policy allows it, you even get around building packages yourself.

The hard part is the step you were missing: determining if a package
changed its config sufficiently so that the old config won't serve any
longer. To update the old config automatically where it is not just a copy
of the default is very difficult to get right. I've been rather unhappy
with some other systems' attempts at doing that [1], and would prefer if I
just got a list spit at me 'these configs need your attention'; but not
every installed system and/or package needs that sort of care, so that
should probably be a preference setting.

regards,
        spz

[1] "apache has a new mime.types and btw your locally adjusted one is gone" -
waahhh!; "screen has a new default screenrc" - well duh, fine, install it.
Your point of wahh may differ :))
-- 
spz%serpens.de@localhost (S.P.Zeidler)