All of lore.kernel.org
 help / color / mirror / Atom feed
From: Phil Blundell <pb@pbcl.net>
To: roman@khimov.ru
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH v2 2/3] base-files: create ${base_bindir} etc. instead of /bin, /sbin and /lib
Date: Sun, 10 Jan 2016 22:18:06 +0000	[thread overview]
Message-ID: <1452464286.1950.15.camel@pbcl.net> (raw)
In-Reply-To: <2644403.ISKvOHQyRX@masala.hex>

On Sun, 2016-01-10 at 20:52 +0300, Roman Khimov wrote:
> IMO, FILES just shouldn't use hard-coded /lib or any other hard-coded path 
> like that.

Well, right, but that doesn't really address the issue.  Even if FILES
is defined in terms of ${base_libdir} or whatever, it's still not going
to match if fixup_perms() has shuffled things around in some random way.
I don't think there is any reliable way for fixup_perms() to find and
patch all the variables that might refer to paths that it has decided to
adjust.

Conversely, if FILES is defined in terms of ${base_libdir} and
do_install() puts the files there, you can change the value of
${base_libdir} to whatever you like and everything will "just work"
without the need for fixup_perms() to move anything.

As I mentioned somewhere else in this thread, micro has been using a
merged /usr for several years (but done the other way around, so
everything is installed into /bin and suchlike) and this has worked just
fine without the need for any fsperms magic.  I can't see any obvious
reason why the new-style /usr merge is fundamentally more difficult.

p.




  parent reply	other threads:[~2016-01-10 22:18 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-02 23:52 [PATCH v2 1/3] kernel: allow kernel module and firmware installation with ${nonarch_base_libdir} != "/lib" Matthias Schiffer
2016-01-02 23:53 ` [PATCH v2 2/3] base-files: create ${base_bindir} etc. instead of /bin, /sbin and /lib Matthias Schiffer
2016-01-04 22:59   ` Mark Hatle
2016-01-04 23:46     ` Matthias Schiffer
2016-01-05  0:16       ` Mark Hatle
2016-01-10 17:13         ` Matthias Schiffer
2016-01-10 17:52           ` Roman Khimov
2016-01-10 18:01             ` Matthias Schiffer
2016-01-10 22:18             ` Phil Blundell [this message]
2016-01-11 15:00           ` Mark Hatle
2016-01-02 23:53 ` [PATCH v2 3/3] base-files: create typical merged /usr symlinks if the "merged-usr" distro feature is set Matthias Schiffer
2016-01-03 13:01   ` Phil Blundell
2016-01-04 22:38     ` Matthias Schiffer
2016-01-05 22:04       ` Phil Blundell
2016-01-04 22:59   ` Mark Hatle

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=1452464286.1950.15.camel@pbcl.net \
    --to=pb@pbcl.net \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=roman@khimov.ru \
    /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.