All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Peter Seebach <peter.seebach@windriver.com>
Cc: "Openembedded-core@lists.openembedded.org"
	<Openembedded-core@lists.openembedded.org>
Subject: Re: Is this a bug? Installed-but-not-packaged warning for a file which is in a package
Date: Thu, 24 Jan 2013 20:05:38 +0000	[thread overview]
Message-ID: <1359057938.3616.16.camel@ted> (raw)
In-Reply-To: <20130123144320.191c91a3@e6410-2>

On Wed, 2013-01-23 at 14:43 -0600, Peter Seebach wrote:
> FILES_${PN} = "fascinating"
> 
> do_install() {
> 	touch ${D}/fascinating
> }
> 
> At least in our local copy of oe-core, this results in:
> 
> 1. A package which contains a /fascinating file.
> 2. An installed-but-unpackaged warning for /fascinating.
> 
> This confused the heck out of me. I eventually figured it out: The "not
> in seen" test is not aware of the possibility of differing path names.
> In general, all path names in FILES_* are being written as absolute
> paths by convention; in the actual code, this is silently corrected by
> the addition of a leading period.
> 
> But an unqualified path works; it's treated as relative to the
> sysroot/image/whatever, and it has the expected behavior. But then we
> insert "fascinating" in seen, and check for "./fascinating" in the next
> phase.
> 
> Possible solution:
> 
> diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
> index b06cca5..9d50a61 100644
> --- a/meta/classes/package.bbclass
> +++ b/meta/classes/package.bbclass
> @@ -981,6 +981,8 @@ python populate_packages () {
>                  file.replace("//", "/")
>              if os.path.isabs(file):
>                  file = '.' + file
> +            if not file.startswith("./")
> +                fle = './' + file
>              if not os.path.islink(file):
>                  if os.path.isdir(file):
> 
> Before I send this as an actual patch and such: Is this behavior a bug?
> If it is a bug, is this the right fix, or should we do something else,
> like reject non-absolute paths?
> 
> Note that just adding a / to files that don't start with one doesn't
> work; there appear to be at least *some* non-absolute paths in some
> packages.

It is a bug and that would appear to be a reasonable fix or fix the
unshipped list construction so it handles items without a . correctly.
I'd take the above patch...

Cheers,

Richard




      reply	other threads:[~2013-01-24 20:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23 20:43 Is this a bug? Installed-but-not-packaged warning for a file which is in a package Peter Seebach
2013-01-24 20:05 ` Richard Purdie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1359057938.3616.16.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Openembedded-core@lists.openembedded.org \
    --cc=peter.seebach@windriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.