If a recipe sets SRC_URI and then appends more items to it with +=
(such as the current rpm recipe in OE-Core), the code in
patch_recipe_file() was failing with a traceback. Work around the
problem for now by dropping the existing lines if we understand the
operation, else just set the value outright at the end. This leaves
something to be desired as it either doesn't respect the existing
structure or leaves a mess but it's better than the current
breakage.

We'll need to come up with a better solution later. Part of the problem
is the existing code structure doesn't allow for patch_recipe_file() to
know what's being added or removed - it only knows the final value that
the caller wants set.

Fixes [YOCTO #9458].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Use bb.utils.edit_metadata() to replace some of the logic in this
function; this avoids us effectively having two implementations of the
same thing. In the process fix the following issues:

* Insert values before any leading comments for the next variable
  instead of after them
* Insert overridden variables (e.g. RDEPENDS_${PN}) in the correct place
* Properly handle replacing varflag settings (e.g. SRC_URI[md5sum])

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Ensure that the user specifies just the name portion instead of a file
name with extension. (We can't just look for . since there are recipe
names such as "glib-2.0" that legitimately contain .).

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

For modify / extract / upgrade, if the specified "recipe" is not
actually a recipe but a virtual target such as virtual/kernel, map it
correctly to the actual recipe and make sure we use that name within the
workspace. Thanks to Chris Larson for reminding me this was still broken
and for a hint on how to fix it.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Signed-off-by: Markus Lehtonen <markus.lehtonen@linux.intel.com>

Instead, simply return the version of the recipe, so that the upstream
version checker will declare that they match.

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

These functions ostensibly allowed parsing a recipe without bbappends
but this clearly hadn't been tested because a variable was unassigned in
both of them in that case.

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Variables such as SRC_URI which are space-separated may also contain
Python expressions (${@...}) which themselves contain spaces that
shouldn't be split when splitting the value into items. In order to
ensure this we need to use a custom splitting function instead of just
string.split().

This issue could be seen when doing "devtool modify sudo", adding a
commit to the resulting source repository then "devtool update-recipe" -
the Python expression in SRC_URI was being unnecessarily broken onto
multiple lines.

Fixes [YOCTO #8046].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

Let's have the caller do this and then the function is a bit more
flexible (e.g. we can choose to parse with bbappends or not); fix up
calls to this function appropriately (of which there are only two, both
within devtool).

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>

Previously only numeric characters were matches and anything else was
discarded, so 4.0-rc3, 2005e, 1.0.2a and similar versions got truncated.

Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>