Alistair Crooks <agc%pkgsrc.org@localhost> writes:
> Depending on the number of packages installed, and the computing power of
> the build system, I've found that
>
> taking a list of the current user-installed packages,
> moving ${PREFIX} out of the way,
> re-bootstrapping (just takes some cycles on NetBSD, needed on other
> platforms),
> and rebuilding each of the packages on the list that was taken
>
> should DTRT, even in the face of major package version bumps (assuming
> python/perl/postgres/mysql and friends are installed as prereq for
> something more usery-level). If there's fallout, nuke the new ${PREFIX} and
> move the last good ${PREFIX} back in its place. I have a simple script to
> achieve this, should anyone want it, but it's kinda hardcoded to me; it
> could be made more generic, though
Yes, but:
that leaves the system unusable until the build finishes
If one does a standard build, yes
If one is on NetBSD and uses sets and pkg_chk or pkg_comp, or a separate build machine (and propagate binary packages from there), no.
And if one is compiling binary packages on any sort of edge machine, well, one is going to get one's just rewards.
And even if that is done -- why???? - there are plenty of times during the day when I can spare the time to update my development machines.
Johnny Lam did a presentation to NYCBUG around 2006 involving switching in a single file with ${PREFIX} populated for packages; it's at
https://www.netbsd.org/gallery/presentations/jlam/xen.html and is focused towards Xen, but talks about swapping pkg.img on the domU to upgrade/rollback packages on the guest.
it's sort of like running a pbulk and binary upgrading
Yup, but doesn't involve setting up pbulk, which can be heavy-handed. It doesn't involve waiting for the dependencies to be checked, either.
it doesn't address how to move from py310-certbot to py311-certbot,
unless you mean to rebuild PKGPATH and ignore PKGNAME
On a system without python installed, and with no python version information specified in mk.conf
cd pkgsrc/security/py-certbot && bmake install
will get the default version of python installed
none of the methods (not a criticism of this one) deal with
incompatible upgrades like databases across major versions
Agreed.
but indeed it is one of the N ways to do it.
It's the best way I've found, assuming space, time, resources and motivations. pkg_rr is useful, but can have its moments, too