All of lore.kernel.org
 help / color / mirror / Atom feed
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 --]

      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 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.