All of lore.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.