All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schiffer <mschiffer@universe-factory.net>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/1] linux-firmware: remove hard-coded paths
Date: Mon, 4 Jan 2016 23:26:17 +0100	[thread overview]
Message-ID: <568AF189.5010801@universe-factory.net> (raw)
In-Reply-To: <568A9E97.2050909@windriver.com>

[-- Attachment #1: Type: text/plain, Size: 1967 bytes --]

On 01/04/2016 05:32 PM, Mark Hatle wrote:
> 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
> 

There seem to be some intresting ideas going around about what can or
should be done via fs-perms.txt... AFAICT, fs-perms.txt can't move
around files, so moving files form /lib to /usr/lib must be done in the
package recipes themselves. (In my opinion, fs-perms.txt is a bad hack
for broken recipes that shouldn't exist anyways, but that's another
discussion)

I think if a distro config changes any of the base paths
({nonarch_,}base_libdir, base_{,s}bindir), *all* packages should respect
this. It's the distro's reponsiblity to create symlinks so everything is
found again at the expected paths (other examples for such hardcoded
paths: /bin/sh; the dynamic linker). See also my patchset I submitted to
this mailing list, which introduces a distro feature to have such
symlinks created by base-files.

Matthias


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2016-01-04 22:26 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
2016-01-04 22:26       ` Matthias Schiffer [this message]
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=568AF189.5010801@universe-factory.net \
    --to=mschiffer@universe-factory.net \
    --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.