From: Martin Jansa <martin.jansa@gmail.com>
To: Janne Karhunen <janne.karhunen@gmail.com>
Cc: Openembedded-core@lists.openembedded.org
Subject: Re: pam related dependency processing bug?
Date: Wed, 25 Mar 2015 21:42:42 +0100 [thread overview]
Message-ID: <20150325204242.GM3904@jama> (raw)
In-Reply-To: <CAE=NcraiB0OH+4EPF=t7_P3B3p_rjbU97-F8MtnROg-48OeumA@mail.gmail.com>
[-- 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 --]
prev parent reply other threads:[~2015-03-25 20:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-25 17:39 pam related dependency processing bug? Janne Karhunen
2015-03-25 18:30 ` Martin Jansa
2015-03-25 20:31 ` Janne Karhunen
2015-03-25 20:42 ` Martin Jansa [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=20150325204242.GM3904@jama \
--to=martin.jansa@gmail.com \
--cc=Openembedded-core@lists.openembedded.org \
--cc=janne.karhunen@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox