From: Ian Campbell <ian.campbell@citrix.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>,
Dave Scott <Dave.Scott@eu.citrix.com>,
Wen Congyang <wency@cn.fujitsu.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
Jonathan Ludlam <Jonathan.Ludlam@eu.citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Ian Jackson <ian.jackson@citrix.com>,
Yang Hongyang <yanghy@cn.fujitsu.com>
Subject: Re: [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo
Date: Tue, 31 Mar 2015 13:03:51 +0100 [thread overview]
Message-ID: <1427803431.2115.116.camel@citrix.com> (raw)
In-Reply-To: <551A80B9.20809@eu.citrix.com>
On Tue, 2015-03-31 at 12:10 +0100, George Dunlap wrote:
> 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@citrix.com> 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.
Correct (for Debian too), but this is more about the RPM maintainers
freedom to choose to enable it or not. Once they chosen their users will
just end up with whatever they chose.
For arch and gentoo folks I suppose this would be a USE var or whatever
they call it.
Ian.
next prev parent reply other threads:[~2015-03-31 12:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 12:46 [PATCH RFC 0/4] tools: Upstream blktap "2.5" as an external repo George Dunlap
2015-03-26 12:46 ` [PATCH RFC 1/4] build: Reorganize and briefly document "external repo" template in tools/Makefile George Dunlap
2015-03-30 9:07 ` Ian Campbell
2015-03-26 12:46 ` [PATCH RFC 2/4] build: Download and build extnernal blktap2.5 repo George Dunlap
2015-03-26 12:55 ` Ian Campbell
2015-03-26 14:04 ` George Dunlap
2015-03-30 14:33 ` Wei Liu
2015-03-30 14:41 ` Ian Campbell
2015-03-30 14:46 ` George Dunlap
2015-03-30 14:50 ` Andrew Cooper
2015-03-30 14:43 ` George Dunlap
2015-03-30 15:38 ` Wei Liu
2015-03-31 9:55 ` George Dunlap
2015-03-31 10:40 ` Stefano Stabellini
2015-03-31 11:10 ` George Dunlap
2015-03-31 12:02 ` Ian Campbell
2015-03-31 12:03 ` Ian Campbell [this message]
2015-03-26 12:46 ` [PATCH RFC 3/4] libxl: Use XenServer's blktap2.5 George Dunlap
2015-03-26 12:46 ` [PATCH RFC 4/4] tools: Remove in-tree blktap2 George Dunlap
2015-03-26 13:50 ` [PATCH RFC 0/4] tools: Upstream blktap "2.5" as an external repo George Dunlap
2015-03-26 15:47 ` Jon Ludlam
2015-03-26 16:08 ` George Dunlap
2015-03-26 16:25 ` Felipe Franciosi
2015-03-26 17:05 ` George Dunlap
2015-03-26 17:12 ` Andrew Cooper
2015-03-26 17:23 ` George Dunlap
2015-03-26 18:06 ` Felipe Franciosi
2015-03-26 16:42 ` Jon Ludlam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1427803431.2115.116.camel@citrix.com \
--to=ian.campbell@citrix.com \
--cc=Dave.Scott@eu.citrix.com \
--cc=Jonathan.Ludlam@eu.citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=ian.jackson@citrix.com \
--cc=stefano.stabellini@eu.citrix.com \
--cc=wei.liu2@citrix.com \
--cc=wency@cn.fujitsu.com \
--cc=xen-devel@lists.xen.org \
--cc=yanghy@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.