Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Alexander Kanavin <alexander.kanavin@linux.intel.com>
To: Max Krummenacher <max.oss.09@gmail.com>,
	openembedded-core@lists.openembedded.org
Cc: Max Krummenacher <max.krummenacher@toradex.com>
Subject: Re: [PATCH v2] libsolv: don't pick up bundled db from host rpm
Date: Tue, 23 May 2017 16:10:09 +0300	[thread overview]
Message-ID: <8ab9f3a0-a3cf-e77d-e615-bfda3b016840@linux.intel.com> (raw)
In-Reply-To: <1495488738.2723.18.camel@gmail.com>

On 05/23/2017 12:32 AM, Max Krummenacher wrote:
>> Sorry Max, this is actually worse than the first version. HAVE_RPM_DB_H
>> has to accurately reflect the presence or absence of the header, as that
>> header is later included or not included depending on that. You cannot
>> set it based on checking some library.
> Well, that is somewhat true.
> The test explicitly tests that the header file is available, but then
> implicitely assumes that when the header file is available no standalone
> needs be linked.
>
> Turning that assumption to explicitly test that rpm.so provides the db
> functionality and from that assuming that rpm/db.h is available is IMHO
> equally right or equally incomplete testing.

The first version of the patch assumes that rpm in oe-core is configured 
to use external db, and hardcodes that assumption.

The second version of the patch assumes that both the library and the 
header are available at the same time. This may be true right now when 
building with bitbake, it is certainly not true in other situations.

I would rather make assumptions about oe-core content, rather than 
bitbake behaviour.

>> So please either fix CHECK_INCLUDE_FILE,
> The reason why I didn't fix it as follows is that this would break
> the test for the non native (target and nativesdk) case.
>
> +  CHECK_INCLUDE_FILE(rpm/db.h HAVE_RPM_DB_H "-nostdinc")
>
> For the non native case the OE rpm headers are actually stored in
> the compiler's standard include path, so searching for rpm/db.h
> with -nostdinc wouldn't pick up the file even if it would exist.

This is not the fix I meant. You are fixing the *use* of 
CHECK_INCLUDE_FILE, but I wanted you to fix the internal content of 
CHECK_INCLUDE_FILE itself, so that it behaves correctly in 
bitbake-driven environment, and does not go out to check host machine 
include paths.

It's fine if the code to be fixed is too arcane or tricky and you cannot 
do it, then let's just revert to the first version of the patch.

Alex


  reply	other threads:[~2017-05-23 13:12 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-19 15:48 [PATCH v2] libsolv: don't pick up bundled db from host rpm Max Krummenacher
2017-05-19 15:51 ` Burton, Ross
2017-05-19 16:08   ` Max Krummenacher
2017-05-22 13:08 ` Alexander Kanavin
2017-05-22 21:32   ` Max Krummenacher
2017-05-23 13:10     ` Alexander Kanavin [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-05-26 20:35 Max Krummenacher
2017-05-29 10:50 ` Alexander Kanavin
2017-05-29 13:00   ` Max Krummenacher
2017-05-29 13:06     ` Max Krummenacher
2017-05-29 15:54       ` Alexander Kanavin
2017-05-29 23:11         ` Richard Purdie

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=8ab9f3a0-a3cf-e77d-e615-bfda3b016840@linux.intel.com \
    --to=alexander.kanavin@linux.intel.com \
    --cc=max.krummenacher@toradex.com \
    --cc=max.oss.09@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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