pam related dependency processing bug?

pam related dependency processing bug?

[Janne Karhunen]

Hi,

Wonder if you guys can share some insights on how to debug this case.
I have a legacy PAM module recipe that says:

DEPENDS_${PN} = "libpam"

'pam' is listed in DISTRO_FEATURES and is working fine. However, for
that pam module libpam dependency is silently dropped during the
build. If PAM happens to be compiled before that module, everything is
fine, but if not, build fails on missing pam headers.

To make this interesting, 'bitbake -g -u depexp <module>' shows the
libpam dependency in place - yet it clearly is not there during the
build. Results are the same for both dizzy and daisy and host OS
doesn't seem to make a difference either.


--
Janne

Re: pam related dependency processing bug?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]

On Wed, Mar 25, 2015 at 10:39:34AM -0700, Janne Karhunen wrote:
> Hi,
> 
> Wonder if you guys can share some insights on how to debug this case.
> I have a legacy PAM module recipe that says:
> 
> DEPENDS_${PN} = "libpam"
> 
> 'pam' is listed in DISTRO_FEATURES and is working fine. However, for
> that pam module libpam dependency is silently dropped during the
> build. If PAM happens to be compiled before that module, everything is
> fine, but if not, build fails on missing pam headers.
> 
> To make this interesting, 'bitbake -g -u depexp <module>' shows the
> libpam dependency in place - yet it clearly is not there during the
> build. Results are the same for both dizzy and daisy and host OS
> doesn't seem to make a difference either.

That's because
DEPENDS_${PN}
doesn't mean anything you should be using DEPENDS (only RDEPENDS,
RPROVIDES, RREPLACES, RCONFLICTS variables are package specific and end
with _<package-name> e.g. _${PN})

> 
> 
> --
> Janne
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: pam related dependency processing bug?

[Janne Karhunen]

Hi,

Thanks, inherited that file and missed that - and my RPM legacy was
thinking that's about right.

How do you guys test people don't leak dependencies with global
DEPENDS? Even this must have been passing by accident quite a while :)


--
Janne

On Wed, Mar 25, 2015 at 11:30 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Wed, Mar 25, 2015 at 10:39:34AM -0700, Janne Karhunen wrote:
>> Hi,
>>
>> Wonder if you guys can share some insights on how to debug this case.
>> I have a legacy PAM module recipe that says:
>>
>> DEPENDS_${PN} = "libpam"
>>
>> 'pam' is listed in DISTRO_FEATURES and is working fine. However, for
>> that pam module libpam dependency is silently dropped during the
>> build. If PAM happens to be compiled before that module, everything is
>> fine, but if not, build fails on missing pam headers.
>>
>> To make this interesting, 'bitbake -g -u depexp <module>' shows the
>> libpam dependency in place - yet it clearly is not there during the
>> build. Results are the same for both dizzy and daisy and host OS
>> doesn't seem to make a difference either.
>
> That's because
> DEPENDS_${PN}
> doesn't mean anything you should be using DEPENDS (only RDEPENDS,
> RPROVIDES, RREPLACES, RCONFLICTS variables are package specific and end
> with _<package-name> e.g. _${PN})
>
>>
>>
>> --
>> Janne
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
> --
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: pam related dependency processing bug?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2076 bytes --]

On Wed, Mar 25, 2015 at 01:31:31PM -0700, Janne Karhunen wrote:
> Hi,
> 
> Thanks, inherited that file and missed that - and my RPM legacy was
> thinking that's about right.
> 
> How do you guys test people don't leak dependencies with global
> DEPENDS? Even this must have been passing by accident quite a while :)

See
openembedded-core/scripts/test-dependencies.sh

but it can detect only dependencies which cause build to fail or
autodetected dependencies which result in extra library being linked
from some binary in the tested package.

> On Wed, Mar 25, 2015 at 11:30 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> > On Wed, Mar 25, 2015 at 10:39:34AM -0700, Janne Karhunen wrote:
> >> Hi,
> >>
> >> Wonder if you guys can share some insights on how to debug this case.
> >> I have a legacy PAM module recipe that says:
> >>
> >> DEPENDS_${PN} = "libpam"
> >>
> >> 'pam' is listed in DISTRO_FEATURES and is working fine. However, for
> >> that pam module libpam dependency is silently dropped during the
> >> build. If PAM happens to be compiled before that module, everything is
> >> fine, but if not, build fails on missing pam headers.
> >>
> >> To make this interesting, 'bitbake -g -u depexp <module>' shows the
> >> libpam dependency in place - yet it clearly is not there during the
> >> build. Results are the same for both dizzy and daisy and host OS
> >> doesn't seem to make a difference either.
> >
> > That's because
> > DEPENDS_${PN}
> > doesn't mean anything you should be using DEPENDS (only RDEPENDS,
> > RPROVIDES, RREPLACES, RCONFLICTS variables are package specific and end
> > with _<package-name> e.g. _${PN})
> >
> >>
> >>
> >> --
> >> Janne
> >> --
> >> _______________________________________________
> >> Openembedded-core mailing list
> >> Openembedded-core@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >
> > --
> > Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]