From: Markus Lehtonen <markus.lehtonen@linux.intel.com>
To: "Burton, Ross" <ross.burton@intel.com>,
Christopher Larson <clarson@kergoth.com>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] base.bbclass wipe ${S} before unpacking source
Date: Wed, 24 Feb 2016 11:59:38 +0200 [thread overview]
Message-ID: <1456307978.2298.47.camel@linux.intel.com> (raw)
In-Reply-To: <CAJTo0LbfEM77HQnq023yLnLA240F8yRywL8b2Wb-dfhnggQ2-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]
On Tue, 2016-02-23 at 18:23 +0000, Burton, Ross wrote:
>
> On 23 February 2016 at 18:01, Christopher Larson <clarson@kergoth.com
> > wrote:
> > db isn't the only recipe doing that. The fetcher unpack method
> > knows where it's unpacking to, I think if anyone should be clearing
> > out the destination first, it should.
> If that's true for tarballs, I agree. I was also wondering if this
> should just be unpack[cleandirs] = ${S}
The problem is that the fetcher does not now the target directory, i.e.
it does not examine the content of tar/zip. Implementing that logic for
different archive formats would require a lot more work.
Using cleandirs sounds good to me. I.e. something like:
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 1372f38..aa107d4 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -133,23 +133,15 @@ python base_do_fetch() {
addtask unpack after do_fetch
do_unpack[dirs] = "${WORKDIR}"
+do_unpack[cleandirs] = "${@d.getVar('S', True) if d.getVar('S', True)
!= d.getVar('WORKDIR', True) else ''}"
python base_do_unpack() {
src_uri = (d.getVar('SRC_URI', True) or "").split()
if len(src_uri) == 0:
return
- rootdir = d.getVar('WORKDIR', True)
-
- # Ensure that we cleanup ${S}/patches
- # TODO: Investigate if we can remove
- # the entire ${S} in this case.
- s_dir = d.getVar('S', True)
- p_dir = os.path.join(s_dir, 'patches')
- bb.utils.remove(p_dir, True)
-
try:
fetcher = bb.fetch2.Fetch(src_uri, d)
- fetcher.unpack(rootdir)
+ fetcher.unpack(d.getVar('WORKDIR', True))
except bb.fetch2.BBFetchException as e:
raise bb.build.FuncFailed(e)
}
[-- Attachment #2: Type: text/html, Size: 2881 bytes --]
next prev parent reply other threads:[~2016-02-24 9:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 11:36 [PATCH] Wipe ${S} before unpacking sources Markus Lehtonen
2016-02-23 11:36 ` [PATCH] base.bbclass wipe ${S} before unpacking source Markus Lehtonen
2016-02-23 13:54 ` Burton, Ross
2016-02-23 18:01 ` Christopher Larson
2016-02-23 18:23 ` Burton, Ross
2016-02-24 9:59 ` Markus Lehtonen [this message]
2016-03-04 10:17 ` Mike Looijmans
2016-03-04 15:17 ` [PATCH] Wipe ${S} before unpacking sources Petter Mabäcker
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=1456307978.2298.47.camel@linux.intel.com \
--to=markus.lehtonen@linux.intel.com \
--cc=clarson@kergoth.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@intel.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