| Submitter | Peter Seebach |
|---|---|
| Date | Jan. 24, 2013, 11:51 p.m. |
| Message ID | <48f475bcf23a8d458fbeb46a96c43f7f09754a34.1359071327.git.peter.seebach@windriver.com> |
| Download | mbox | patch |
| Permalink | /patch/43335/ |
| State | New |
| Headers | show |
Comments
Patch
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) ]
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 <peter.seebach@windriver.com> --- meta/classes/package.bbclass | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-)