A path name in FILES_package which has no leading slash can work for the packaging code, causing the file to get installed correctly as part of a package; however, the check for installed but unpackaged files checks against the "./" path, resulting in a spurious diagnostic. Solution: We're already prepending a period to every absolute path. If a path has gotten past that, and doesn't start with "./", it's presumably a relative path, and adding "./" to it will make it match.
The test case is to create a file in the root directory, and include the file's name with no leading slash in a FILES_*. Without this, the file should actually get packaged, but generate an installed-but-unpackaged warning anyway. Signed-off-by: Peter Seebach <[email protected]> --- meta/classes/package.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass index 8e07168..ee18488 100644 --- a/meta/classes/package.bbclass +++ b/meta/classes/package.bbclass @@ -980,6 +980,8 @@ python populate_packages () { file.replace("//", "/") if os.path.isabs(file): file = '.' + file + if not file.startswith("./") + file = './' + file if not os.path.islink(file): if os.path.isdir(file): newfiles = [ os.path.join(file,x) for x in os.listdir(file) ] -- 1.7.0.4 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
