Re: how to upgrade a whole machine ...

[Herb Peyerl <hpeyerl%beer.org@localhost>]

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  
part...

>   (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  
this.  ie:

(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 ...

Thanks Dieter.