| |
|
 |
|
 |
|
|
|
| |
|
|
xen-api
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
|
|
|
| |
|
Home