Curt Sampson <cjs@NetBSD.org> writes:

> Given the level of differences between Xen 3.1 and 3.2 (to the point
> where the 3.1 tools don't work on 3.2), it seems fairly obvious to me
> that we want to start including the minor version number in the package
> names (at lest for xen 3), and also generated files where we can do
> this. So unless anybody has any objections, I am going to start with
> this:
>
>     1. Rename xenkernel3 and xentools3 to xenkernel31 and xentools31.
>
>     2. Change xenkernel2 and xenkernel31 to generate kernel files named
>     "xen2.gz" and "xen-3.1.2.gz" (and of course similar for the debug
>     kernels).
>
>     3. Add a xenkernel32 package that generates a kernel named "xen-3.2.0.gz"
>
>     4. Add notes to the DESCR files for xen 3 packages noting that the
>     3.1 and 3.2 tools are not compatable.

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.

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.

Changing the package name doesn't cause much trouble for automated
update - it's changing the directory in pkgsrc that's troublesome.