tech-pkg archive

[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 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,, 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.

Home | Main Index | Thread Index | Old Index