From: Denys Dmytriyenko <denis@denix.org>
To: openembedded-devel@lists.openembedded.org
Subject: Re: package_ipk.bbclass fails due to a wrong version of a package
Date: Tue, 07 Apr 2009 17:34:12 -0400 [thread overview]
Message-ID: <20090407213412.GF11203@denix.org> (raw)
In-Reply-To: <20090407162432.GA11203@denix.org>
On Tue, Apr 07, 2009 at 12:24:32PM -0400, Denys Dmytriyenko wrote:
> On Thu, Apr 02, 2009 at 04:38:32PM -0400, Denys Dmytriyenko wrote:
> > On Thu, Apr 02, 2009 at 12:11:18PM -0700, Tom Rini wrote:
> > > On Thu, Apr 02, 2009 at 02:50:06PM -0400, Denys Dmytriyenko wrote:
> > >
> > > > I've been debugging this issue for a while now w/o much success.
> > > >
> > > > We have following recipes in play:
> > > > curl_7.19.0.bb
> > > > curl-native_7.18.2.bb
> > > > curl-sdk_7.18.2.bb
> > > >
> > > > None of those set PV explicitly, so they are picked up from the filename.
> > >
> > > Hmm, if you throw in a -v -DDD and log all the output, do you see both
> > > curl_7.18.2.bb being loaded (for -sdk) and curl_7.19.0.bb (for target)
> > > being loaded up?
> >
> > Nope. While trying to build curl-sdk_7.18.2.bb there is no mentioning of
> > 7.19.0 (grepped the output) until the do_package_write_ipk, where it tried to
> > create a lock file, as I mentioned above:
> >
> > NOTE: package curl-sdk-7.18.2-r0: task do_package_write_ipk: started
> > DEBUG: mkdirhier(/oe/tmp/work/i686-i686-sdk-angstrom-linux/curl-sdk-7.18.2-r0/image)
> > DEBUG: mkdirhier(/oe/tmp/work/i686-i686-sdk-angstrom-linux/curl-7.19.0-r1/image)
> > ERROR: Error, lockfile path does not exist!: /oe/tmp/work/i686-i686-sdk-angstrom-linux/curl-7.19.0-r1/install
> >
> > The second mkdirhier() is where it fails and it is called from lockfile(),
> > which gets called from do_package_ipk()...
> >
> > BTW, this was a i686-generic build, thus i686-i686-sdk path...
>
> FYI, I figured it out few days ago, but had some personal matters to resolve
> first. I'll be sending a detailed explanation and a patch soon.
Ok, the problem comes from the 1af5030de05a1e65d1de734f7675ffc22c8318fc
commit taken from Poky, which seems legitimate, as it "fixes" the generation
of pkgdata/runtime files by adding extra fields, such as PN, PV and PR. It was
commited as part of RPM packaging.
Unfortunately, that unmasks some issues, namely the one with curl/curl-sdk...
All curl recipes use a single .inc file, which expands the PACKAGES variable
with libcurl name (i.e. "curl curl-dev curl-dbg libcurl libcurl-dev...").
Now when curl target is packaged, it generates a pkgdata file with version
7.19.0-r1 in it under arch dir. Next, when curl-sdk is being packaged its
PACKAGES variable is "curl-sdk curl-sdk-dev curl-sdk-dbg libcurl
libcurl-dev...". So when do_package_write_ipk() calls
read_subpackage_metadata(), it looks for pkgdata of libcurl and finds it in
arch dir first, extracting the wrong version numbers, hence lockfile() trying
to access the wrong directory. Here is the code:
def get_subpkgedata_fn(pkg, d):
import bb, os
archs = bb.data.expand("${PACKAGE_ARCHS}", d).split(" ")
archs.reverse()
pkgdata = bb.data.expand('${TMPDIR}/pkgdata/', d)
targetdir = bb.data.expand('${TARGET_VENDOR}-${TARGET_OS}/runtime/', d)
for arch in archs:
fn = pkgdata + arch + targetdir + pkg
if os.path.exists(fn):
return fn
return bb.data.expand('${PKGDATA_DIR}/runtime/%s' % pkg, d)
Now, the above code works in Poky, because Poky has the same version numbers
for curl, curl-native and curl-sdk.
Maybe there is way to fix this issue in the core classes, but I don't believe
libcurl should be in curl-sdk PACKAGES anyway. I have it fixed this way and
I'll be sending the patch to the list shortly. Plus, curl-sdk is only needed
for do_stage() and has empty do_install() anyway.
The above commit from Poky may unmask some other similar issues, not related
to curl - for example the one Otavio reported recently. It can be easily
verified if it is the rootcause:
$ git revert -n 1af5030de05a1e65d1de734f7675ffc22c8318fc
If there are multiple pkgdata files with the same name, but different
contents, the above quoted get_subpkgedata_fn() function may pick the wrong
one. The question is - is it even valid to have something like this:
${TMPDIR}/pkgdata/armv5te-none-linux-gnueabi/runtime/foo
${TMPDIR}/pkgdata/i686-armv5te-sdk-none-linux-gnueabi/runtime/foo
--
Denys
next prev parent reply other threads:[~2009-04-07 21:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-02 18:50 package_ipk.bbclass fails due to a wrong version of a package Denys Dmytriyenko
2009-04-02 19:11 ` Tom Rini
2009-04-02 20:38 ` Denys Dmytriyenko
2009-04-07 16:24 ` Denys Dmytriyenko
2009-04-07 21:34 ` Denys Dmytriyenko [this message]
2009-04-07 22:02 ` [PATCH] curl: move PACKAGES and FILES_* from the .inc file Denys Dmytriyenko
2009-04-07 22:27 ` Tom Rini
2009-04-07 23:24 ` Denys Dmytriyenko
2009-04-08 0:01 ` Tom Rini
2009-04-08 17:06 ` package_ipk.bbclass fails due to a wrong version of a package Otavio Salvador
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=20090407213412.GF11203@denix.org \
--to=denis@denix.org \
--cc=openembedded-devel@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