[Xen-API] RFC: Shuffling xen-api-libs

[Jonathan Ludlam <Jonathan.Ludlam@xxxxxxxxxxxxx>]

Hi all,

In order to get xen-api-libs into Debian, it's got to be in a reasonable state. 
I believe we're quite a long way off reasonable at the moment, so I'd just like 
to send out a Plan of Action to define how we're going to get from where we are 
to where we need to be.

These are the findlib packages that we currently produce:

camldm - ocaml interface to device mapper
cdrom - a module to query the current state of the cdrom device (e.g. tray 
open, audio disk inserted, etc)
close-and-exec: a small helper program that closes open file descriptors and 
execs a binary. 
cpuid - bindings to the cpuid assembly instruction
forking_executioner: a helper executable for fork-and-execing binaries without 
having to worry about pthread problems
http-svr: Our http server
log: a logging library
mlvm: an LVM library
netdev: Networking utilities 
pciutil: Utility library for parsing pci ids
rpc-light: Ocaml type value marshalling/unmarshalling and rpc client/server 
generator
rss: very simple rss feed generator
sexpr: s-expression marshaller and unmarshaller
stdext: Our 'standard extension' library
stunnel: Small utility for executing stunnel and maintaining a cache of ready 
stunners [side note: Apple's Mail autocorrects stunnel to be 'stunner' :-]
tapctl: Library for interacting with blktap's tapctl command
udev: basic library for listening to udev events
vhd: bindings to libvhd
xen-utils: library to manipulate xen's command line (via a helper script!)
xml-light2: an xml-light compatible shim over xmlm
uuid: A simple non-compliant uuid library

I suggest we cause the following packages to become modules within stdext

cdrom
close-and-exec <-- do we still need this?
cpuid
forking_executioner
log <-- should be top-level?
netdev
pciutil
rss
sexpr
stunnel
tapctl
udev
xen-utils
uuid
xml-light2 <-- should die anyway

and that we move camldm into mlvm,  which leaves the following top-level 
packages:

http-svr
mlvm
rpc-light
stdext
vhd

I also think that several of these have poor names, and I suggest the following:

xapi-http-svr
mlvm
rpc-light
xapi-libs
libvhd

As an alternative suggestion, we could move some of the packages into a new, 
different xapi-libs, and spring clean stdext to remove all of the cruft.

We may want to use rpc-light from its own repository, too 
(github.com/samoht/rpc-light)

So, is this a crazy plan? Does anyone agree/disagree/have an opinion? 

Jon





 
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api