On 10 Jan 2003 22:25:01 -0600, Greg A. Woods wrote:
> [ On , January 11, 2003 at 01:20:33 (GMT), MLH wrote: ]
>> Subject: Re: everything is a dependency and preventing removal
>>
>> The last few days I have been experimenting with pkg_comp/pkg_chk
>> for doing this sort of thing, and it almost works. There are a few
>> hitches here and there still, but between them, they seem to do a
>> pretty good job of attempting an update without trashing your
>> running environment.  pkg_comp doesn't quite create the mk.conf
>> file the way I understand it is supposed to ('DEPENDS_TARGET=package'
>> is not the default as stated and EXTRAMK doesn't appear to work).
>> The last missing piece, as I see it, is to then be able to move
>> the newly-created binary packages out into the real environment so
>> that pkg_chk could install them.
> 
> I'm not sure what you're getting at here and how this might address any
> of the concerns I raised.
> 
> Most of the issues I raised have to do with the package database, not
> how you initially configure and build a package in isolation.

Yep, we are talking about the same thing.

  pkg_comp is a tool that makes easy the compilation of packages
  inside a clean chroot environment.  This allows an easy tracking
  of exact dependencies and the correct behavior of a package in
  a fresh system installation.

Now that doesn't mean it has to be a real 'fresh' installation...
You can have it mimic your current environment if you have been
building binary packages by default (or switch to it), and then
feed your current list of packages to the chroot environment. The
chroot then can mimic as much of your current package system as
you want (or more) and then you can use pkg_chk to test building
the updates automatically from source. It's pretty cool. I had
written a collection of scripts for doing this, and had toyed with
having two independent pkg systems around, one of use and one for
building, but I found IMO that there are too many hard-coded
dependencies and weird catches in the pkgsrc system to do it. Thus
why I took a look at using chroot via pkg_comp. I filled out two
config files, one for pkg_comp and one for pkg_chk - which I already
had - listing the packages I needed without their dependencies.
Then I launched pkg_comp, entered chroot and ran pkg_chk. It took
off updating the chroot copy. I toyed with ways to confuse it, and
ran cvs up to get real updates, and pkg_chk handled them fine -
all with no mess to my running systems while everything was being
automatically updated. I then moved the binary packages (my big
gripe) over to the real binary package tree and used pkg_chk outside
of chroot to update the real packages.

As I said, I've been experimenting with this the last few days and
it appears to (almost) work pretty darned well. The good part is
that if an update fails or doesn't do what you intended, you can
easily nuke the chroot and rebuild it back to the original mirror
and try again or fix it. The only thing missing (unless I can't
see it) is a way to roll the new chroot binary packages in over
the old ones.

Yeah, it takes up a little big of diskspace and if you are only
maintaining one box, maybe this is a little overkill, but I'm not
so sure about that. If the package roll-over was implemented, I
think I'd do it even for one box.

Maybe try it...