public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: Matthias Schiffer <mschiffer@universe-factory.net>
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: Mon, 11 Jan 2016 09:00:53 -0600	[thread overview]
Message-ID: <5693C3A5.4010301@windriver.com> (raw)
In-Reply-To: <5692911F.1050601@universe-factory.net>

On 1/10/16 11:13 AM, Matthias Schiffer wrote:
(Trimming to just this comment)

> * I stand by my opinion that moving files automatically is a bad idea,
> and the FILES issue mentioned in the other thread further backs my point
> (besides that issue, I've mentioned relative symlinks and relative paths
> in general as problems that can break packages when their files are moved).

The issue is simply that MANY packages have a fixed way they install things, and
then other actions (do_install) "move" them around to the expected place.  We
follow that behavior with the fs-perms.txt and "move them around".

The only alternative I can think of is to move the fs-perms.txt processing at
the beginning of do_install.  It could then create the symlinks and directories
mentioned.  Then the install occurs and the tools would need to know how to deal
with it "or fail".  (I don't like the or fail..)

The other problem though is this would introduce a number of (potentially) empty
directories to the a given recipe's install which would kick off the QA
warnings.  (We'd need to resolve that issue first.)

> My proposal would be to change the fs-perms.txt handling to only check
> if nothing conflicts with default symlinks, but not to create or move
> anything. This is another point I'd like to get more input on.

The key here, it can be a lot of additional work (based on experience) to have
to go in and change the locations that things are installing components.  Things
that PROPERLY use gnu autoconf, and other variable systems have an advantage
here, but it's not unusual to see references to '/lib' (i.e. the /lib/firmware
case), or even to '/sbin' for the non "/usr/sbin" case.

We really want this path change, and setup to be seemless for the distro
developer.  Set up the values in the distro configuration (path variables and
fs-perms.txt in some cases) and provide necessary .bbappends or distro specific
version of base-files package.  Theoretically that SHOULD be all that is
required to define the 'filesystem'.

--Mark


  parent reply	other threads:[~2016-01-11 15:00 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
2016-01-11 15:00           ` Mark Hatle [this message]
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=5693C3A5.4010301@windriver.com \
    --to=mark.hatle@windriver.com \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox