openembedded-core.git/meta/classes/package.bbclass, branch dizzy

split_and_strip_files: regroup hardlinks to make build deterministic

2015-05-15T17:13:18+00:00

Reverted 7c0fd561bad0250a00cef63e3d787573112a59cf

Created separate group of hardlinks for the files inside
the same package. This should prevent stripped files to be
populated outside of package directories.

This turns out not to be straightforward and has overlap with the
other hardlink handling code in this area. The code is condensed
into a more concise and documented form.

[Original patch from Ed with tweaks from RP]

[YOCTO #7586]

(From OE-Core master rev: 82d00f7254b7d3bb6a167d675d798134884d1b19)

Signed-off-by: Ed Bartosh 
Signed-off-by: Richard Purdie

package.bbclass: Let PR server update PKGV, not PV

2015-02-11T17:39:51+00:00

PV is the package version as we need it to be during the build. PKGV is the
final version as it ends up in the package, and defaults to PV.

The packager handled builds without PR-server by replacing the AUTOINC string
in PKGV, but when the PR-server is being used, the script replaces the contents
of PKGV with the PV if the PV contains "AUTOINC". Thus the packager overrides
any change to PKGV the recipe might have made.
This breaks classes like gitpkgv that provide a correctly numbered PKGV, the
number as calculated by that class will simply be replaced with a 0-based index
from the PR-server.

This patch makes the packager look at the PKGV version instead of the PV, and
update the PKGV only based on the PKGV contents as set by the recipe.

See also the discussion here:
http://lists.openembedded.org/pipermail/openembedded-core/2015-January/100329.html

From investigating the history of the code and changes in the past year, the
use of "pv" instead of "pkgv" appears to be just an oversight, introduced in:
commit b27b438221e16ac3df6ac66d761b77e3bd43db67 "prs: use the PRServer to replace the BB_URI_LOCALCOUNT functionality"
A later commit 865d001de168915a5796e5c760f96bdd04cebd61 "package/prserv: Merge two similar functions into one"
silently fixed this only for the case without PR-server by using pkgv there.

(From OE-Core rev: 7895c0a67d381ff66668fca5207bd196f36c91db)

Signed-off-by: Mike Looijmans 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

package/prserv: Merge two similar functions into one

2015-02-11T17:39:51+00:00

Having these two separate functions handling PR values seems pointless,
and worse, there are impossible code branches mixed within them.

Merge them into one function and tweak comments so at least you
don't have to read both functions to figure out what is going on.

This does restructure the conditionals to try and aid readability.

(From OE-Core rev: 865d001de168915a5796e5c760f96bdd04cebd61)

Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

package.bbclass: Fix support for private libs

2015-02-11T17:39:49+00:00

* n is a tuple since this commit:
  commit d3aa7668a9f001044d0a0f1ba2de425a36056102
  Author: Richard Purdie 
  Date:   Mon Jul 7 18:41:23 2014 +0100
  Subject package.bbclass: Improve shlibs needed data structure

  since then 'n in private_libs' was always false and private libs
  were always processed
* this is bad when we have libfoo in private libs, but also some package
  providing libfoo, that way we ship own libfoo.so, but together with
  runtime dependency on package providing libfoo

(From OE-Core rev: ec1d379683cedca4be1c252475d02c8041227142)

Signed-off-by: Martin Jansa 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

package.bbclass: do variable fixups even when FILES was set

2014-12-31T10:17:50+00:00

A number of settings (DESCRIPTION, SUMMARY, postinst, postrm,
and appends to RDEPENDS) were made only if FILES_foo was not
set for a given package. If you had a modified glibc packaging
setup that was defining FILES_glibc-gconv-somelocale, this would
prevent the automatic append of glibc-gconv as a dependency,
because extra_depends was ignored.

I think the assumption may have been that if FILES_foo was set,
DESCRIPTION_foo and SUMMARY_foo would also be set, but it seems
to me that the right answer is probably to set them if they aren't
already set, and leave them alone if they are.

(From OE-Core rev: 7e59b0c7e03fc08a6eaf9c8ccb6bfa72b4604cc5)

Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

package.bbclass: Create empty key/value if not there for shlib_provider

2014-12-31T10:17:34+00:00

When we use ASSUME_SHLIBS,e.g.

ASSUME_SHLIBS = "libEGL.so.1:libegl-implementation"

then we end up with errors like below when using shlibs2 (dizzy+)

File: 'package_do_shlibs', lineno: 216, function: package_do_shlibs
     0212:            dep_pkg = dep_pkg.rsplit("_", 1)
     0213:            if len(dep_pkg) == 2:
     0214:                lib_ver = dep_pkg[1]
     0215:            dep_pkg = dep_pkg[0]
 *** 0216:            shlib_provider[l][libdir] = (dep_pkg, lib_ver)
     0217:
     0218:    libsearchpath = [d.getVar('libdir', True),
d.getVar('base_libdir', True)]
     0219:
     0220:    for pkg in packages.split():
Exception: KeyError: 'libEGL.so.1'

This is because the entry which is being populated does not exist
so lets create it if its not already there.

Change-Id: I9e292c5439e5d1e01ea48341334507aacc3784ae
(From OE-Core rev: a64f81fcef42172f788cec7a63bb4672eac99f94)

Signed-off-by: Khem Raj 
Signed-off-by: Ross Burton 
Signed-off-by: Richard Purdie 
Signed-off-by: Armin Kuster

package_do_shlibs: Look for provider in the path thats in shlib_provider dictionary

2014-10-10T21:40:37+00:00

shlib2 code puts the information about path where a provider
will be found. e.g.

{'/usr/lib/llvm3.3': ('libllvm3.3-llvm-3.3', '3.3')}

This is obtained from new shlib2 pkgdata from

llvm3.3/3.3-r0/pkgdata/shlibs2/libllvm3.3-llvm-3.3.list

However when we search for NEEDED libraries we ignore the
key above which is the path where the provider library is installed
and instead just seach in libdir and base_libdir and hence
libraries which are not in above standard search paths gets
ignored even if they appear in DT_NEEDED sections

and a note is emitted

NOTE: Couldn't find shared library provider for libLLVM-3.3.so, used by
files: ....

IMO this note should actually become an error since if we do
not have all DT_NEEDED libraries in image the system is dysfunctional.

This patch extracts this libpath from key and add it to seach paths
when looing for a provider of a shared library

[YOCTO #6798]

Change-Id: Ie5f08632e37ba8d3439c8aaae33bc68b8996792f
Signed-off-by: Khem Raj 
Signed-off-by: Richard Purdie

package.bbclass: Reverse runtime symlinks should be tied to package generation

2014-10-06T14:07:59+00:00

In case a package is not generated (is empty and does not has allow
empty flag set) the package data regarding reverse runtime dependency
shouldn't be done.

This were causing a false-positive in the meta-fsl-arm layer, when
building mesa, as:

,----[ Error during build of MX53 in meta-fsl-arm ]
| ERROR: The recipe mesa is trying to install files into a shared area
|  when those files already exist. Those files and their manifest
|  location are:
|    /.../build/build/tmp/sysroots/imx53qsb/pkgdata/runtime-reverse/libopenvg-dev
|    Matched in manifest-imx53qsb-amd-gpu-x11-bin-mx51.packagedata
| Please verify which recipe should provide the above files.
`----

Fixes [YOCTO: #6795]

Signed-off-by: Otavio Salvador 
Signed-off-by: Richard Purdie

package: Correct two typos in a comment

2014-08-29T22:42:57+00:00

This quite coincidentally invalidates the sstate for do_package which
is needed due to the correction of oe.utils.multiprocess_exec().

Signed-off-by: Peter Kjellerstedt 
Signed-off-by: Richard Purdie

package: Disable runtime mapping of RPROVIDES/RCONFLICTS/RREPLACES

2014-08-23T22:01:51+00:00

It doesn't really make sense to run the remapping code on these
variables. If specific renaming is needed, it should be applied
manually. This means that the debian RPROVIDES of the original package
name can be preserved. There was also a bug report about this on the
OE-Core mailing list recently where someone else ran into this problem
too.

Signed-off-by: Richard Purdie