[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Heh, you're probably right, bad example.

Good examples of findlib packages that should definitely die:

xen-utils (utility to finesse the calling of a script to modify the xen command 
uuid (not really uuids at all, just random strings in a particular format)
xml-light2 (only exists because we didn't have time to change xapi to use xmlm 

So what I'm looking for is general consensus about which things should go and 
which shouldn't. Sounds like cpuid might be useful in its own right, maybe. Are 
there others?

On 28 Oct 2011, at 11:32, Vincent Hanquez wrote:

> On 10/28/2011 08:38 AM, Jonathan Ludlam wrote:
>> There's not much point in, e.g. the cpuid module being it's own findlib 
>> package. For some of the larger ones, there's a more reasonable argument 
>> (e.g. log). That's the whole point. Which modules do you feel should have 
>> their own findlib package?
> I think cpuid was probably the worst example :-), as Anil mentioned, it's 
> useful 
> in its own rights. As a similar example it's also available as a single small 
> package in haskell [1].
> Of course having a descent build system make it convenient (or not) to have 
> small packages, and that's why i'd made the breaked up xapi-libs in the first 
> place where each directoried had its own oasis build system.
> [1] http://hackage.haskell.org/package/cpuid
> -- 
> Vincent

xen-api mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.