From: Phil Blundell <pb@pbcl.net>
To: Mark Hatle <mark.hatle@windriver.com>
Cc: "openembedded-core@lists.openembedded.org"
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 1/1] linux-firmware: remove hard-coded paths
Date: Tue, 05 Jan 2016 22:20:30 +0000 [thread overview]
Message-ID: <1452032430.2002.110.camel@pbcl.net> (raw)
In-Reply-To: <568BF822.8020303@windriver.com>
On Tue, 2016-01-05 at 11:06 -0600, Mark Hatle wrote:
> This is a situation where we've got hard coded '/lib' entries in FILES, but
> we're trying to move the directory elsewhere.... 'adjusting' FILES automatically
> is probably more error prone and complicated then desired.. but I'm not sure
> switching to nonarch_baselib_dir is right either.. argh. (But it may certainly
> be the less evil in this case.)
Isn't this more or less exactly what ${nonarch_baselib_dir} is for? If
there's some disconnect between firmware and other users of that
variable (mostly mdev/udev/systemd I guess) then maybe we should
introduce a separate ${firmware_loader_dir} or something. But either
way, it seems fairly clear that the right thing is to simply have a
variable that the distro can set to the right place, and then have both
do_install() and FILES defined in terms of that same variable, rather
than doing some sort of subsequent post-processing step that tries to
move the contents around and then patch FILES up to match.
p.
prev parent reply other threads:[~2016-01-05 22:20 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
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 [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=1452032430.2002.110.camel@pbcl.net \
--to=pb@pbcl.net \
--cc=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.