Re: [Xen-devel] [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

On 03/31/2015 11:40 AM, Stefano Stabellini wrote:
> On Tue, 31 Mar 2015, George Dunlap wrote:
>> On Mon, Mar 30, 2015 at 4:38 PM, Wei Liu <wei.liu2@xxxxxxxxxx> wrote:
>>>>> IMHO we need to support --with-system-blktap= in configure in case
>>>>> distro wants to package blktap separately. Not sure if in practice this
>>>>> makes sense since AIUI blktap is only used by Xen.
>>>>
>>>> I agree that would be ideal; however, it's not so simple, because at the
>>>> moment libxl links directly against libblktap.  This would mean:
>>>>
>>>> 1) Changing libxl so that it could dynamically detect the presence of
>>>> the proper version of libblktap at runtime and use the stubbed-out
>>>> defaults if not available.
>>>>
>>>
>>> This should be done in ./configure too, not during libxl build /
>>> runtime.  If libblktap is not present during ./configure  then libxl
>>> just use stubs.
>>
>> It sounds like you're talking about introducing a hard dependency,
>> such that packages that use a libxl built this way won't function
>> without blktap installed.  Yeah, that's simple enough.
>>
>> I'm not super experienced in the distro packaging mindset, but since
>> (AFAIK) no other programs or projects use blktap, is there much point
>> to having a separate repo if you can't "opt-out" of installing it?
> 
> It is not an hard dependency: as long as one doesn't use VHDs, ones
> doesn't see any difference whether blktap is installed on not.

I'm talking about a hard dependency *for the resulting package*.

If libxl built linked against libblktap, and libblktap is not installed
on the system, then won't running the binary at all result in "Can't
find shared library" errors?

In any case, I'm pretty sure that if you build an RPM and link against a
particular library, that the RPM will then refuse to install if that
library isn't available.

> In that case we should probably not have blktap in the xen-unstable
> tree, because we wouldn't want to have so divergent community models
> for different component in the same source repository.

Community model doesn't matter to me; what matters to me is the
practical question of whether we can upstream what we need to upstream.
 An upstream that was in theory open but in practice difficult to work
with or hostile to our patches would be a lot worse than an upstream
that was in theory closed but in practice cooperative and took
everything we sent them.

I don't expect there to be any major changes required upstream, and so I
think that in practice this won't be an issue.  If it ever does become
an issue, then we can decide what to do about it at that time.

The reason I put it so strongly is that I want to make sure that there
are no hard feelings if we end up having to go separate ways.  The
XenServer team are doing us a favor, and haven't promised a large amount
of development time or commitment.  I think what they're willing to
offer will be sufficient for what we need.

> However we could make it easier to built libxl and blktap together, we
> could also add blktap to OSSTest and Raisin
> (http://marc.info/?l=xen-devel&m=142779794216955).

I wouldn't mind moving all external repos (qemu-*, seabios, ovmf,
blktap, &c) out of the Xen tree as soon as Raisin is mature enough to do so.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel