Pkg xen devel - Aug 2007 - propossed 3.1 changes

Hi folks

I propose the following changes for 3.1:
- Rename source to xen-3. Upstream stripped one part of the version, so
  the next should be 3.2.
- pygrub as extra package.
- Rename i386 to i386-nonpae
- Rename i386-pae to i386. PAE is upstream default now and pae images
  works with a 64bit hypervisor.

We should think about supporting libvirt. It provides an AFAIK stable
interface on the unstable libxen interfaces. Maybe something like the
following will work:
- Add libxen-X.
- Build a libvirt against each of them.
- Set the directory with this lib in /etc/ld.so.conf.d/xen-common if xen
  is running.
Or we drop the support to have more than one sort of utils installed.

Bastian

-- 
No one wants war.
		-- Kirk, "Errand of Mercy", stardate 3201.7

On Wed, Aug 01, 2007 at 01:07:50PM +0200, Bastian Blank
wrote:
> I propose the following changes for 3.1:
- Use quilt. We have now a rather large quantity of patches and dpatch
  is no help in pushing them forward to new version. I will try if quilt
  helps there.

Bastian

-- 
Beam me up, Scotty, there's no intelligent life down here!

Bastian Blank wrote:
> Hi folks
>
> I propose the following changes for 3.1:
> - Rename source to xen-3. Upstream stripped one part of the version, so
>   the next should be 3.2.
> - pygrub as extra package.
> - Rename i386 to i386-nonpae
> - Rename i386-pae to i386. PAE is upstream default now and pae images
>   works with a 64bit hypervisor.
>
>   
    I think these are all good ideas.  I don't think we need to keep
separate minor versions so going with a xen-<major ver num> packaging
name would make sense. As PAE is default it further makes sense to make
it the default i386 package and have non-PAE separate.
> We should think about supporting libvirt. It provides an AFAIK stable
> interface on the unstable libxen interfaces. Maybe something like the
> following will work:
> - Add libxen-X.
> - Build a libvirt against each of them.
> - Set the directory with this lib in /etc/ld.so.conf.d/xen-common if xen
>   is running.
> Or we drop the support to have more than one sort of utils installed.
>
> Bastian
    From my experience libvirt has appeared stable and I've been
examining Fedora's Xen implementation and utilities that use it. Using
the ld.so.conf.d dir structure will allow us to support different
implementations if any come along so it is a wise forward-thinking decision.

    Beyond that I know I've been absent a lot lately and hoping to start
working to remedy that. Cross-country move and now trying to finish
buying our first house and move into it while on my 3rd new job in 1
year. As soon as I get my devel workstation back online I'll be getting
everything updated and see where I can concentrate on helping to get
back up to speed.

    Regards,
    Jeremy

On Wed, Aug 01, 2007 at 02:08:01PM +0200, Guido Trotter
wrote:
> On Wed, Aug 01, 2007 at 01:07:50PM +0200, Bastian Blank wrote:
> > I propose the following changes for 3.1:
> > - Rename source to xen-3. Upstream stripped one part of the version,
so
> >   the next should be 3.2.
> to xen-3.1, then... right?
No, to xen-3.
> > - pygrub as extra package.
> > - Rename i386 to i386-nonpae
> > - Rename i386-pae to i386. PAE is upstream default now and pae images
> >   works with a 64bit hypervisor.
> 
> I agree with the changes, + quilt if it helps...
Okay.
> > We should think about supporting libvirt. It provides an AFAIK stable
> > interface on the unstable libxen interfaces. Maybe something like the
> > following will work:
> > - Add libxen-X.
> > - Build a libvirt against each of them.
> > - Set the directory with this lib in /etc/ld.so.conf.d/xen-common if
xen
> >   is running.
> > Or we drop the support to have more than one sort of utils installed.
> Isn't libxen now supposed to be stable? Anyway I agree on building it
in 3.1...
libxen seems so. libxc, libxs not. Which one is used by libvirt?

Bastian

-- 
You're dead, Jim.
		-- McCoy, "Amok Time", stardate 3372.7

Hi

At 1185966470 time_t, Bastian Blank wrote:
> I propose the following changes for 3.1:
> [...]
No objections from my pov.

Cheers,
-- 
Julien Danjou
.''`.  Debian Developer
: :' : http://julien.danjou.info
`. `'  http://people.debian.org/~acid
  `-   9A0D 5FD9 EB42 22F6 8974  C95C A462 B51E C2FE E5CD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20070801/f46bd5f2/attachment.pgp

On Wed, Aug 01, 2007 at 02:12:10PM +0200, Bastian Blank
wrote:
> Which one is used by libvirt?
libvirt seems to link libxenstore.

Bastian

-- 
War is never imperative.
		-- McCoy, "Balance of Terror", stardate 1709.2

On Wed, Aug 01, 2007 at 02:22:10PM +0200, Bastian Blank
wrote:
> On Wed, Aug 01, 2007 at 02:12:10PM +0200, Bastian Blank wrote:
> > Which one is used by libvirt?
> libvirt seems to link libxenstore.
It uses only libxenstore. The xenstore abi is not stable. Sample:
| -struct xs_transaction_t;
| -typedef struct xs_transaction_t * xs_transaction_t;
| +typedef uint32_t xs_transaction_t;

Bastian

-- 
Our missions are peaceful -- not for conquest.  When we do battle, it
is only because we have no choice.
		-- Kirk, "The Squire of Gothos", stardate 2124.5

On Wed, Aug 01, 2007 at 01:07:50PM +0200, Bastian Blank
wrote:
> - pygrub as extra package.
I don't longer think this is a good idea. Better include it in the utils
package, it is really small anyway.

Bastian

-- 
Warp 7 -- It's a law we can live with.

Bastian Blank wrote:
> [...]
> We should think about supporting libvirt. It provides an AFAIK stable
> interface on the unstable libxen interfaces.
Apart from the fact that it might be interesting to support and use
libvirt for other reasons, there's also the XenAPI which is supposed to
be a more stable API for local and remote control of Xen systems,
directly from upstream.

As of libvirt, there is an ITP for it since quite some AFAIK and you
should maybe look at what's happening there to not make the same effort
twice.
> [...]
> Or we drop the support to have more than one sort of utils installed.
Apart from some people fiddling with many different Xen versions on one
machine who have to change these often for testing, development and
documentation, I don't see why there must be multiple libs supported.

And then, these people(me included) can be expected they have other ways
to get ther multiple lib installs.
The upside of having ony one lib, and the different versions having a
"Conflicts"  against each other is, it's cleaner then, beacuse I
can
always be sure that I have the right lib installed and used when
testing, and the danger that I accidentally use the python libs of 3.0.3
with the hypervisor 3.1 is gone.

The things that are done to support these multiple libs (e.g. wrappers
around some stuff that is just found in /usr/bin on standard upstream
Xen installs) just make stuff more complex, I think.

Henning