public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
* [PATCH 0/1] installed but unpackaged... foul lies and calumnies
@ 2013-01-24 23:51 Peter Seebach
  2013-01-24 23:51 ` [PATCH 1/1] package.bbclass: Consistency between packaging and unpackaged check Peter Seebach
  0 siblings, 1 reply; 2+ messages in thread
From: Peter Seebach @ 2013-01-24 23:51 UTC (permalink / raw)
  To: Openembedded-core@lists.openembedded.org

If a FILES_* variable has an unqualified path in it, this can result in
a file  being sucessfully packaged, and yet, still showing up as
installed-but-unpackaged. Note: I had weird build problems with my oe-core
tree, but I tested this in a nearby poky tree and it worked there, anyway.

The following changes since commit 2e2a91025ca9c113365c810ce08b48201fe792b8:
  Khem Raj (1):
        systemd: Fix build on ppc

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib seebs/unpackaged
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=seebs/unpackaged

Peter Seebach (1):
  package.bbclass: Consistency between packaging and unpackaged check

 meta/classes/package.bbclass |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)




^ permalink raw reply	[flat|nested] 2+ messages in thread

* [PATCH 1/1] package.bbclass: Consistency between packaging and unpackaged check
  2013-01-24 23:51 [PATCH 0/1] installed but unpackaged... foul lies and calumnies Peter Seebach
@ 2013-01-24 23:51 ` Peter Seebach
  0 siblings, 0 replies; 2+ messages in thread
From: Peter Seebach @ 2013-01-24 23:51 UTC (permalink / raw)
  To: Openembedded-core@lists.openembedded.org

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(-)

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




^ permalink raw reply related	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2013-01-25  0:07 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-24 23:51 [PATCH 0/1] installed but unpackaged... foul lies and calumnies Peter Seebach
2013-01-24 23:51 ` [PATCH 1/1] package.bbclass: Consistency between packaging and unpackaged check Peter Seebach

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox