[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: how to upgrade a whole machine ...
On 7-May-08, at 7:44 AM, Dieter Baron wrote:
Firstly, if the default settings are okay for you, you can use
binary packages from the official bulk build. That is relatively
easy, just point pkg_chk at the official binary package repository.
(Being able to provide binary packages for non-default option settings
is on the roadmap.)
Do any of these approaches look acceptable for you, and would making
them easier and better documented address your concerns?
I think your first suggestion looks most probable, unfortunately,
when I looked (last tuesday) there were no 4.0 binary packages so I
assumed my only choice was to build them myself. I see now that
Manuel built some later last week so it was simply bad timing on my
(I'm compiling a list of things we need to address to make pkgsrc
usable for users (with reasonable effort), so we have a plan where we
need to go and how to get there.)
I don't know what the general case is. I feel like my situation is,
or should be relatively common. I had an old 3.0 machine with
packages installed manually (cd /usr/pkgsrc/foo; make install) that I
wanted to upgrade to the current release. Once NetBSD proper was
upgraded, I needed to upgrade my installed packages.
To make this task less daunting, a general 'recipe' and tools to do
(0) what is the generally accepted way to accomplish this?
(1) do I blow away my existing /usr/pkg and start from scratch? Or
do I use pkg_comp to build a new /usr/pkg in a chroot, and then mv my
old one out of the way and the new one into place?)
(2) if I use pkg_comp, how do I start building a pkg_comp.conf file?
Can one be auto generated using pkgdepgraph?
(3) why do I have to make a pkg_chk.conf from scratch? Can't pkg_chk
use my pkg_comp $AUTO_PACKAGES?
You know what'd be cool? a "pkg_update" that optionally fetches all
the binary/sets, relevant source, builds a chroot, does a
pkgdepgraph, and points the user at his/her new /usr/pkg and/or
binary packages... Even cooler would be a list of package specific
config files that will need to be migrated (dovecot.conf, httpd.conf,
mysql.cf, blah blah blah blah). Also cool would be a 'pkg_update
suggest" sort of thing that goes through my $AUTO_PACKAGES and says
"you're running apache1, consider switching to apache2" or "consider
switching to bash3 instead of bash2", or what have you...
It seems to me (as a pkgsrcnewbie) that all the pieces are basically
there, but none of them know how to talk to one another or require
too much black magic to make work correctly...
This isn't by any means, me saying "you all suck" because obviously
there's a lot of hard work being put in here... I feel, however, as
though maybe we've lost track of the end user in all of this ...
Main Index |
Thread Index |