On Wed, 2011-10-05 at 09:24 +0100, Andre Przywara wrote:
> On 10/04/2011 05:00 PM, Ian Campbell wrote:
> > On Tue, 2011-10-04 at 15:48 +0100, Andre Przywara wrote:
> >> On 09/30/2011 12:39 PM, Ian Campbell wrote:
> >>> On Fri, 2011-09-30 at 11:35 +0100, Anthony PERARD wrote:
> >>>> On Fri, Sep 30, 2011 at 08:36, Ian Campbell<ian.campbell@xxxxxxxxxx>
> >>>> wrote:
> >>>> ...
> >>>> You probably want to check the yajl headers as well, no ?
> >>>> #include<yajl/yajl_parse.h>
> >>>> #include<yajl/yajl_gen.h>
> >>>
> > ...
> >> Also wouldn't it be nicer to link this small library statically? This
> >> would omit the runtime requirement at all.
> >> The test team just spelled yajl as "yet another library to get Xen
> >> running"...
> >
> > I don't think this is necessary, it's just a library you need to install
> > and for most users the packaging system will transparently cover this.
> > All the usual reasons for not statically linking stuff apply here.
> > There's nothing special about that wrt Xen and/or the size of the
> > library.
>
> Unfortunately this package is not omnipresent in the distributions.
> Though I find it already in Fedora 13, it is not in the official RHEL5
> repos, also not in anything before OpenSuSE 11.4 and before SLES11SP2.
> This creates quite some hassle for any people using one of these systems
> to build and run Xen. And pulling it from github will push most people
> (like me ;-) into version 2 in the first place.
Hrm, that's unfortunate. It seems to be the only even vaguely widespread
JSON library for C so I'm not sure there was much alternative here given
that we have to speak JSON in order to speak QMP to upstream Qemu.
AIUI it is usually sufficient to find either a binary RPM from a closely
related distro (i.e. a newer version of said distro or e.g. OpenSUSE for
SLES) or to find a .src.rpm and run rpmbuild on it. I don't suppose
these distros have the equivalent of Debian's backports.org? If
necessary we should have a page on the wiki which gives pointers to
where to obtain these libraries.
> But I guess this will not convince you to drop it from unstable. That's
> why I thought static linking
But to statically link you must have already obtained the library from
somewhere, right? So statically linking doesn't really help.
> (or including in the tree?)
Absolutely not.
IMHO the Xen repos should not be ingesting/bundling every project or
library which we want to make use of. We have done this in the past
(i.e. libaio) and it was a mistake.
There is nothing wrong with a project having dependencies on libraries
and other various software. We should strive to clearly document these
dependencies but we should not feel obliged to import them into the Xen
repos.
Including stuff in the Xen tree makes it harder for our downstreams
(i.e. distros, who want to use the existing packages of a library not
some bundled version) to package Xen in a sane way and adds to
maintenance burden, both for us and them.
> >> Also be advised that it looks like this is relying on version 1 of yajl.
> >> It looks like the new version 2.0.1 is not compatible, I got compile
> >> errors with the newer version. If the stable version 1.x is required,
> >> this should be stated somewhere or at least checked properly in check_yajl.
> >
> > Any idea what we could test for here?
>
> The sanest way would be to do it like configure and check explicitly for
> the data structure that we rely on, but I guess just looking for a
> symlink called libyajl.so.1 in /usr/lib64 should suffice here.
>
>
> >>> diff -r 302b7556edd9 -r de602616358b tools/check/check_yajl_lib
> >>> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> >>> +++ b/tools/check/check_yajl_lib Fri Sep 30 11:39:35 2011 +0100
> >>> @@ -0,0 +1,6 @@
> >>> +#!/bin/sh
> >>> +# CHECK-BUILD CHECK-INSTALL
> >>> +
> >>> +. ./funcs.sh
> >>> +
> >>> +has_lib libyajl.so || fail "can't find libyajl.so"
>
> +has_lib libyajl.so.1 || fail "can't find libyajl.so version 1"
Thanks, I'll regroove the patch with that and the other suggestion about
CHECK-INSTALL.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home