On 2008-01-23 08:23 -0500 (Wed), Greg Troxel wrote:

> That sounds fine, modulo my usual plea against a lot of renaming, so I
> suggest that after you do this that we forever stick with
> sysutils/xenkernelXY for xen X.Y.Z, with new packages added and old ones
> removed, but always keeping the version in PKGPATH.  That makes
> automatic tools never do an update, but that seems fine in this case.

I am perfectly happy with that. I was also planning to rename the kernel
directories, so that instead of

	xenkernel:	xen-kernel/xen.gz
	xenkernel3:	xen3-kernel/xen.gz

we have:

	xenkernel:	xen-kernel/xen-2.x.x.gz
	xenkernel31:	xen-kernel/xen-3.1.2.gz
	xenkernel32:	xen-kernel/xen-3.2.0.gz

This makes it obvious what the heck the kernels are, and makes it easy
to copy several different versions to / for experimenting with different
configs in menu.lst. Comments or objections, anyone?

> It seems like while you could install multiple kernels (since they
> have distinct names), the tools will conflict. So perhaps the
> sysutils/xentools32 directory should create the xentools-3.2.x
> package. Or, it could create xentools32-3.2.1, but then you need
> CONFLICTS+ in all xentools packages, and that seems messier.

We should have CONFLICTS right now; we already get in trouble if you
build xentools20 and xentools3 on the same system. So I'll make all of
sysutils/xentools* build a xentools-n.n.n package if nobody thinks it's
going to cause problems. Is there an example somewhere of another group
of packages that does this that I can use as a template?

cjs
-- 
Curt Sampson       <cjs@starling-software.com>        +81 90 7737 2974   
Mobile sites and software consulting: http://www.starling-software.com