I was just looking for a cpuid package just the other day in fact. It seems
like the perfect thing to split out: standalone and non-trivial enough to have
a small package for.
There are two concerns here for upstreaming (to Debian and beyond): build pain
and namespace. Having multiple binary/findlib packages generated from a single
xen-api-libs source package seems reasonable, and users building from source
would continue to only clone a single repository.
Namespace is a bigger problem; many of those findlib packages will be quite
xen-specific. How about just prepending xen- on everything that depends on the
xapi extlib?
This way, the packages that are truly standalone like cpuid will not need the
prefix, and could be used by other people (and eventually have their own
repositories, for example with git-submodule if appropriate). This would also
help gradually migrate common systems functions into Core from Jane Street too
--- they have non-portable bindings to various sysconf(3) functions also, and
I've been porting it to OpenBSD and factoring things out.
Anil
On 28 Oct 2011, at 08:38, 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?
>
> Jon
>
>
> On 28 Oct 2011, at 05:38, Vincent Hanquez wrote:
>
>> On 10/27/2011 11:43 PM, Jonathan Ludlam wrote:
>>> 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.
>>
>>> So, is this a crazy plan? Does anyone agree/disagree/have an opinion?
>>
>> I think, that's sad that it's going in the wrong direction. module should
>> have a
>> chance to become useful in their own right, not be stuffed in a xapi-only
>> munbo
>> jumbo of modules. This nullify the splitting work too and somewhat goes
>> against
>> the debian way of packaging.
>>
>> --
>> Vincent
>>
>> _______________________________________________
>> xen-api mailing list
>> xen-api@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/mailman/listinfo/xen-api
>
>
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api
>
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
Home