Subject: alternate pkg tree
To: None <tech-pkg@netbsd.org>
From: James K. Lowden <jklowden@schemamania.org>
List: tech-pkg
Date: 11/07/2002 21:26:05
I think I have a plausible plan for making pkgsrc upgrades easier and less
hair-raising.  I'm interested in comments you might have and suggestions
for how to implement it.  

I keep pkgsrc up to date with sup(1), but I dread upgrading my packages,
because one itsy bitsy tweak at the bottom of the dependency tree can mean
putzing with my environment for eons.  I'm looking for a way to upgrade
things with less havoc than "make update" can create.  

My thinking is to rebuild my favorite stuff whenever an update arrives,
but write somewhere else instead of /usr/pkg.  I'd like the "task list"
(of my favorite stuff) to be driven by /var/db/pkg, but I suspect it may
become necessary to mark some packages as "don't deinstall" to control the
process somewhat.  I think of it as something like a tailored bulk build,
with the additional feature that the regular system is unaffected.  

The script might run every night or every week, and would report what
worked and what didn't.  Eventually I'd get lucky, and my alternate tree
would be completely built.  I'd

	mv /usr/pkg /usr/pkg.old
	mv /usr/pkg.new /usr/pkg
	startx

and start running my new system.  If I had a problem, falling back would
be trivial.  

I've left out some things, not least of which is X11 and /etc.  Maybe
chroot(8) is an answer here, but as I'm a friend of the environment and
have no experience as warden, I'm hoping some combination of pkgsrc magic
can accomplish what I'm trying to do.  

Anyone else think this is a good idea?

--jkl