[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 
line)
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 
properly)

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?

Jon
  
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
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api


 


Rackspace

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