[oe] [meta-oe][PATCH 3/3] libldb: make openldap optional, but default

[Khem Raj]

On Wed, Nov 11, 2015 at 10:17 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>
>> Am 11.11.2015 um 19:10 schrieb Khem Raj <raj.khem at gmail.com>:
>>
>> On Wed, Nov 11, 2015 at 9:47 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>
>>>> Am 11.11.2015 um 18:34 schrieb Khem Raj <raj.khem at gmail.com>:
>>>>
>>>> On Wed, Nov 11, 2015 at 1:11 AM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>>>
>>>>>> Am 11.11.2015 um 04:26 schrieb Khem Raj <raj.khem at gmail.com>:
>>>>>>
>>>>>>>
>>>>>>> On Nov 10, 2015, at 1:26 PM, Jens Rehsack <rehsack at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Since openldap isn't required, but used when found, allow qualified
>>>>>>> users to disable the requirement to save some space.
>>>>>>>
>>>>>>> Signed-off-by: Jens Rehsack <sno at netbsd.org>
>>>>>>> ---
>>>>>>> meta-oe/recipes-support/libldb/libldb_1.1.17.bb | 5 ++++-
>>>>>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/meta-oe/recipes-support/libldb/libldb_1.1.17.bb b/meta-oe/recipes-support/libldb/libldb_1.1.17.bb
>>>>>>> index 44f061a..07a839d 100644
>>>>>>> --- a/meta-oe/recipes-support/libldb/libldb_1.1.17.bb
>>>>>>> +++ b/meta-oe/recipes-support/libldb/libldb_1.1.17.bb
>>>>>>> @@ -4,9 +4,12 @@ SECTION = "libs"
>>>>>>> LICENSE = "LGPL-3.0+ & LGPL-2.1+ & GPL-3.0+"
>>>>>>>
>>>>>>> DEPENDS += "libtdb talloc libtevent popt"
>>>>>>> -RDEPENDS_${PN} += "libtevent popt libtalloc openldap"
>>>>>>> +RDEPENDS_${PN} += "libtevent popt libtalloc"
>>>>>>> RDEPENDS_pyldb += "python libtdb libtalloc"
>>>>>>>
>>>>>>> +PACKAGECONFIG ??= "ldap"
>>>>>>> +PACKAGECONFIG[ldap] = ",,openldap"
>>>>>>> +
>>>>>>> SRC_URI = "http://samba.org/ftp/ldb/ldb-${PV}.tar.gz \
>>>>>>>         file://do-not-import-target-module-while-cross-compile.patch \
>>>>>>>        "
>>>>>>> --
>>>>>>> 1.9.1
>>>>>>>
>>>>>>> This results from analysing why there's still an openldap ...
>>>>>>>
>>>>>>> I know, having no knob to disable ldap is dirty, but there is no such switch.
>>>>>>> Even more dirty, the switch in samba_4% is for embedded samba3 source-base only,
>>>>>>> the ldb bundled with samba4 just uses ldap when found.
>>>>>>>
>>>>>>> The patch relies on the idea of qualified users - those who know that they
>>>>>>> don't want ldap, disable it everywhere and whistle.
>>>>>>
>>>>>> it seems to not fix the problem completely, for exact reasons that some other package may bring in openldap and stage it before this recipe is built so you
>>>>>> have exact same problem again. I think if this package is patched to add a knob to disable/enable openldap support explicitly then the fix will be complete and I am sure upstream will also accept such a patch.
>>>>>
>>>>> NO! Please read carefully what "qualified user expected" means!
>>>>>
>>>>
>>>> I understand it well. no we don't want any user tiers here. We should
>>>> tend towards becoming user friendly
>>>> A qualified user is well equipped to maintain a patch with a
>>>> RDEPENDS_${PN}_remove in his layer.
>>>
>>> Both aspects have their pros and cons, but ...
>>>
>>>>> Forcing a dependency because someone else might introduce it either
>>>>> is insane - and adding RDEPENDS is just hiding the symptom, not
>>>>
>>>> its bringing determinism to build thats an important aspect.
>>>
>>> ... this argument beats them all. Nothing to add ;)
>>>
>>> Anyway - for determinism, openldap should be in depends then, not
>>> RDEPENDS, shouldn't it?
>>
>> it would translate into a build time dependency
>
> Which is reasonable:
>
> <bluelightning> sno: RDEPENDS just means that it's going to be the packaging tasks of the recipe depending on those of the recipes producing the named packages, as opposed to DEPENDS where do_configure depends on do_populate_sysroot of the mentioned items
>
> Otherwise, build_1 (which has no other recipe requiring openldap) would build
> without openldap support but sucking in the package, build_2 would be build
> with ldap support.

rare but that seems possible case, so adding a DEPEND along with
RDEPEND is a good idea to cover it up.

>
>>>>> fixing the root cause. The root cause is, that waf is broken
>>>>> by design.
>>>>
>>>> such sweeping statements have to backed by reasoning otherwise no one
>>>> will take them seriously. IMO if you atleast report
>>>> this to waf community someone else might be able to help fixing
>>>> whatever the problem is.
>>>
>>> But shouldn't the samba maintainer do that?
>>
>> May be/maybe not I dont know, I even dont know whats broken in waf,
>> you did not explain that
>
> Having an option or not, in autoconf you can set
>
> ac_cv_HAVE_LDAP_H=no
>
> and the test results in "checking for ldap.h: no" - regardless the
> existence of ldap.h. waf doesn't have such an option, has it?
>
> Cheers
> --
> Jens Rehsack - rehsack at gmail.com
>
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel