From: Markus Lehtonen <markus.lehtonen@linux.intel.com>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 0/6] devtool: improve handling of local source files
Date: Thu, 11 Jun 2015 15:53:07 +0300 [thread overview]
Message-ID: <1434027187.12084.54.camel@linux.intel.com> (raw)
In-Reply-To: <4504055.vUCZMjBN1g@peggleto-mobl.ger.corp.intel.com>
Hi Paul,
On Thu, 2015-06-04 at 14:49 +0100, Paul Eggleton wrote:
> On Thursday 04 June 2015 16:12:07 Markus Lehtonen wrote:
> > On Tue, 2015-05-12 at 19:01 +0100, Paul Eggleton wrote:
> > > On Thursday 30 April 2015 12:16:06 Markus Lehtonen wrote:
> > > > This patchset tries to improve handling of local source files (i.e.
> > > > file://
> > > > in SRC_URI). First, it improves packages for which S=WORKDIR (that
> > > > possibly
> > > > only have local sources. Second, it makes local sources available in the
> > > > srctree for all packages.
> > > >
> > > > See yocto bug #7602
> > >
> > > I've finally looked at these, apologies for the delay. Some comments:
> > >
> > > * I don't think we really want the local files to become part of the git
> > > repository by default - they shouldn't be committed. Once users have
> > > finished with devtool, we want them to be able to push the source tree to
> > > their own repo and point to that within the recipe, whilst keeping the
> > > local files next to the recipe.
> >
> > So you suggest to add a new command line option to devtool extract and
> > modify (--local-files or smth)? What to do when there are only local
> > files (no source tarball / repo) - automatically enable --local-files in
> > this case?
>
> Is another option really required? Unless I'm missing something, I would have
> thought the behaviour for local files ought to be the same regardless of
> whether they are in addition to the upstream source, or the only files in
> SRC_URI.
Currently, the local files are already committed into Git in some cases
(i.e. basically when S==WORKDIR, e.g. with makedevs).
What would you suggest to do with the local files? Copy the files to git
repo worktree but add them to .git/info/exclude? Or not copy them at
all? In this case some packages would not be supported anymore (e.g. the
makedevs mentioned before).
I agree that the behavior should be consistent and the same regardless
of the existence of upstream sources.
> > > * This implies that new files added to the local files dir when we do
> > > devtool update-recipe should not be added as a patch, they should be
> > > copied next to the recipe and added to SRC_URI. I'm more than happy for
> > > us to implement this separately as a follow-up (i.e. we could start by
> > > not handling adding files to the local files directory at all.)
> >
> > Yeah, I actually have this WIP. Currently (i.e. with the current
> > patchset), new files added to 'local-files' are just ignored. They are
> > not copied and no patches is generated out of these.
>
> OK, then it sounds like the behaviour for added files is reasonable for the
> moment and we can extend it as a follow-up.
OK, thanks.
> > > * The local-files directory needs to be named specific to OE -
> > > "oe-local-files" would be ideal. If we could have one place in the code
> > > where this was defined that would be ideal as well (maybe at some point
> > > we'd allow it to be configured).
> >
> > This is not a big deal. Should it perhaps be "bb-local-files" instead?
>
> Well strictly speaking all of this is being defined in OE, not bitbake, hence
> my suggestion of "oe-local-files".
OK, "oe-local-files" is probably fine. I was just thinking about Poky or
some other derived project where the files might not be from OE.
Thanks,
Markus
prev parent reply other threads:[~2015-06-11 12:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-30 9:16 [PATCH 0/6] devtool: improve handling of local source files Markus Lehtonen
2015-04-30 9:16 ` [PATCH 1/6] devtool: extract: remove patches when S=WORKDIR Markus Lehtonen
2015-04-30 9:16 ` [PATCH 2/6] recipeutils: implement get_recipe_local_files() Markus Lehtonen
2015-04-30 9:16 ` [PATCH 3/6] oe.patch.GitApplyTree: add paths argument to extractPatches Markus Lehtonen
2015-04-30 9:16 ` [PATCH 4/6] devtool: update-recipe: update local files directly Markus Lehtonen
2015-04-30 9:16 ` [PATCH 5/6] devtool: extract: always import local files to srctree Markus Lehtonen
2015-04-30 9:16 ` [PATCH 6/6] devtool: modify: make bitbake use local files from srctree Markus Lehtonen
2015-05-12 18:01 ` [PATCH 0/6] devtool: improve handling of local source files Paul Eggleton
2015-06-04 13:12 ` Markus Lehtonen
2015-06-04 13:49 ` Paul Eggleton
2015-06-11 12:53 ` Markus Lehtonen [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=1434027187.12084.54.camel@linux.intel.com \
--to=markus.lehtonen@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=paul.eggleton@linux.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 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.