On Thu, Jan 24, 2008 at 07:54:04AM +0900, Curt Sampson wrote:
> 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?

Fine with me

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

I'm not sure what this would do with bulk builds. Would they still build
all versions of the package ?

Also, if you do 'pkg_add xentools' it'll take the one with the higher
version number. keepin 31 or 32 in the package name avoids this
problem.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--