All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] linux-firmware: remove hard-coded paths
Date: Mon, 4 Jan 2016 10:32:23 -0600	[thread overview]
Message-ID: <568A9E97.2050909@windriver.com> (raw)
In-Reply-To: <568A99CD.9000800@universe-factory.net>

On 1/4/16 10:11 AM, Matthias Schiffer wrote:
> On 01/04/2016 02:14 PM, Ian Ray wrote:
>> The recipe uses hard-coded paths (specifically /lib) in do_install
>> and in FILES, however on a merged /usr system this directory might
>> not exist. Prefer base_libdir.
>>
>> Signed-off-by: Ian Ray <ian.ray@ge.com>
>> ---
> 
> This should use nonarch_base_libdir, base_libdir defaults to /lib64 on
> ppc64, which is not where the firmware is expected.
> 

At a minimum, I would agree nonarch_base_libdir, however..

I believe that the kernel loader/modules/tools themselves actually have '/lib'
hard coded into them.  This is the reason why /lib/firmware was used and not one
of the variables.

This is one of the cases were /lib is actually correct, since that is what the
system is expecting.  We can make some kind of accommodation for systems where
/lib -> /usr/lib... but that should be done inside of the filesystem setup
processing and not the package itself.  (I'm referring to the
'meta/files/fs-perms.txt' file.

--Mark


  reply	other threads:[~2016-01-04 16:32 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-04 13:14 [PATCH 0/1] More fixes for a distro with a merged /usr Ian Ray
2016-01-04 13:14 ` [PATCH 1/1] linux-firmware: remove hard-coded paths Ian Ray
2016-01-04 16:11   ` Matthias Schiffer
2016-01-04 16:32     ` Mark Hatle [this message]
2016-01-04 22:26       ` Matthias Schiffer
2016-01-04 22:56         ` Mark Hatle
2016-01-04 23:57           ` Matthias Schiffer
2016-01-05  0:28             ` Mark Hatle
2016-01-05  1:26               ` Matthias Schiffer
2016-01-05 14:03                 ` Mark Hatle
2016-01-05 14:04                 ` Ray, Ian (GE Healthcare)
2016-01-05 14:33                   ` Mark Hatle
2016-01-05 14:41                     ` Ray, Ian (GE Healthcare)
2016-01-05 17:06                       ` Mark Hatle
2016-01-05 22:20                         ` Phil Blundell

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=568A9E97.2050909@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.