All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Nyström" <david.nystrom@enea.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: "meta-virtualization@yoctoproject.org"
	<meta-virtualization@yoctoproject.org>
Subject: Re: PACKAGECONFIG variables.
Date: Wed, 5 Dec 2012 11:25:01 +0100	[thread overview]
Message-ID: <50BF20FD.3060602@enea.com> (raw)
In-Reply-To: <50BE773C.7080905@linux.intel.com>

On 12/04/2012 11:20 PM, Saul Wold wrote:
> On 12/04/2012 01:43 PM, David Nyström wrote:
>> Ray,
>>
>> Yes, of course. Let's add a *-minimal package configs,
>> if none are set, we'll let it autodetect + add full dependencies
>> otherwise.

> Won't using autodetect cause inconsistencies depending on how the image
> gets built,

Yes, if by inconsistencies you mean that binary package will differ 
depending on sysroot content, i.e. DEPENDS.

 > it will also lead to a lot larger dependency requirement.
Not nessecarily, since DEPENDS might be dynamically added with 
PACKAGECONFIG variables. But I understand what you are aiming at here.

> I know it's better to have a known list of what's in and what's out.
> Autoconf has caused inconsistencies in the past, when options are not
> specified.

I understand and agree, autodetect does wreak havoc on DEPEND/RDEPEND 
semantics, since some packages tries to autodetect RDEPENDS, which will 
have to be placed in DEPENDS to able to be properly autodetected.

I suspect regressions are also caught in buildtime when having it either 
on or off, rather than having autoconf errors detected in runtime. I'll 
adjust accordingly.

Best Regards,
David

>
> Sau!
>
>> Is it OK for you if I set it to auto detect by default? , this would
>> imply
>> a local.conf addition to optimize for footprint.
>> I'm guessing package config selects cannot be set from an image file,
>> I'll give that a try tomorrow.
>>
>> Br,
>> David
>>
>> Sent from my Android phone using TouchDown (www.nitrodesk.com)
>>
>> -----Original Message-----
>> *From:* Raymond Danks [ray.danks@se-eng.com]
>> *Received:* Tuesday, 04 Dec 2012, 18:38
>> *To:* David Nyström [David.Nystrom@enea.com]
>> *CC:* Prica, Mihai [mihai.prica@intel.com];
>> meta-virtualization@yoctoproject.org
>> [meta-virtualization@yoctoproject.org]
>> *Subject:* Re: [meta-virtualization] PACKAGECONFIG variables.
>>
>> David,
>>
>> XenAPI is used by XenServer and Xen Cloud Platform.  There is currently
>> no underlying metadata support for these packages, so this should be
>> disabled.
>>
>> I do, in fact have binary size constraints.  I see where you are going
>> with this, but would it be possible instead to add a "detect" or "all"
>> to PACKAGECONFIG?  I suppose an alternative would be to add "*-minimal"
>> to PACKAGECONFIG which tweak the configure to create minimal build
>> configurations.
>>
>> Ray
>>
>> On 12/04/2012 09:03 AM, David Nyström wrote:
>>> I have some issues with how PACKAGECONFIG works, do you guys mind if I
>>> disable all --without functionality in PACKAGECONFIG, and let libvirt
>>> ./configure autodetect dependencies ?
>>> This will result in a bigger libvirt binary, and
>>> libnl, netcf, augeas, polkit dependencies being mandatory for all
>>> users of libvirt, unless explicitly disabled by the "xen" PACKAGECONFIG.
>>>
>>> Does anyone have any binary size constraints ?
>>>
>>> Br,
>>> David
>>>
>>> On 12/04/2012 04:49 PM, Prica, Mihai wrote:
>>>>
>>>> Hi,
>>>>
>>>> The error is because configure is called with the --with-xenapi
>>>> option. I think there is a bug in the recipe at the
>>>> PACKAGECONFIG[xen] line. It should be --without-xenapi instead of the
>>>> first --with-xenapi. I don't know exactly what xenapi does, Raymond
>>>> can give you more details here.
>>>>
>>>> Try to change this and see if it works.
>>>>
>>>> Thanks,
>>>> Mihai
>>>>
>>>> -----Original Message-----
>>>> From: David Nyström [mailto:david.c.nystrom@gmail.com]
>>>> Sent: Tuesday, December 04, 2012 5:36 PM
>>>> To: Raymond Danks
>>>> Cc: Prica, Mihai; meta-virtualization@yoctoproject.org
>>>> Subject: PACKAGECONFIG variables.
>>>>
>>>> Hi All,
>>>>
>>>> When trying to upgrade to libvirt-1.0, I'm getting some strange errors.
>>>> How could this pass with the old libvirt I dont know.
>>>>
>>>> Is the XenAPI driver something you explicitly build and use ?
>>>>
>>>> ------------------------------------------------------------------
>>>> checking for xen_vm_start in -lxenserver... no
>>>> configure: error: You must install the XenServer Library to compile
>>>> XenAPI driver with -lxenserver Configure failed. The contents of all
>>>> config.log files follows to aid debugging
>>>> /media/sdb5/eel/build/tmp/work/x86_64-poky-linux/libvirt-1.0.0-r1/libvirt-1.0.0/config.log
>>>>
>>>> This file contains any messages produced by compilers while running
>>>> configure, to aid debugging if configure makes a mistake.
>>>>
>>>> It was created by libvirt configure 1.0.0, which was generated by GNU
>>>> Autoconf 2.69.  Invocation command line was
>>>>
>>>>     $
>>>> /media/sdb5/eel/build/tmp/work/x86_64-poky-linux/libvirt-1.0.0-r1/libvirt-1.0.0/configure
>>>>
>>>>
>>>> --build=x86_64-linux --host=x86_64-poky-linux
>>>> --target=x86_64-poky-linux --prefix=/usr --exec_prefi x=/usr
>>>> --bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/libexec
>>>> --datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com
>>>> --localstatedir=/var --libdir=/usr/lib --includedir=/usr/incl ude
>>>> --oldincludedir=/usr/include --infodir=/usr/share/info
>>>> --mandir=/usr/share/man --disable-silent-rules
>>>> --disable-dependency-tracking
>>>> --with-libtool-sysroot=/media/sdb5/eel/build/tmp/sysroots
>>>> /qemux86-64 --with-python=yes
>>>> --with-python-inc-dir=-I/media/sdb5/eel/build/tmp/sysroots/qemux86-64/usr/include/python2.7
>>>>
>>>>
>>>> --enable-nls --without-hyperv --with-remote --without-openvz
>>>> --without- phyp --without-augeas --with-xen --with-xenapi
>>>> --with-libxl=/media/sdb5/eel/build/tmp/sysroots/qemux86-64/lib
>>>> --with-xen-inotify --with-macvtap=no --without-esx --without-vbox
>>>> --without-polkit --without-lxc --without-uml --with-test=yes
>>>> --with-libvirtd --without-qemu --without-yajl --without-vmware
>>>>
>>>>
>>>> Br,
>>>> David
>>>> _______________________________________________
>>>> meta-virtualization mailing list
>>>> meta-virtualization@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>>>
>>
>>
>>
>> _______________________________________________
>> meta-virtualization mailing list
>> meta-virtualization@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>


      reply	other threads:[~2012-12-05 10:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-04 15:35 PACKAGECONFIG variables David Nyström
2012-12-04 15:49 ` Prica, Mihai
2012-12-04 16:03   ` David Nyström
2012-12-04 17:38     ` Raymond Danks
2012-12-04 21:43       ` David Nyström
2012-12-04 22:20         ` Saul Wold
2012-12-05 10:25           ` David Nyström [this message]

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=50BF20FD.3060602@enea.com \
    --to=david.nystrom@enea.com \
    --cc=meta-virtualization@yoctoproject.org \
    --cc=sgw@linux.intel.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.