All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ross Burton <ross.burton@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: [RFC] Move libexecdir to $prefix/libexec
Date: Tue, 23 Jun 2015 15:30:01 +0100	[thread overview]
Message-ID: <1435069807-13557-1-git-send-email-ross.burton@intel.com> (raw)

Hi,

Yes, I'm bringing this up again. :)

Our default of libexecdir=$libdir/$BPN is contrary to both the FHS[1] and GNU
Coding Standards[2], mainly because the key point is that libexecdir should be
global and not change per-recipe.  The new FHS allows /usr/libexec so this
series changes the default to that, and fixes up the recipes which need fixing.

Several of the recipe fixes are unrelated to the change and will be submitted to
master shortly, but others (eg sudo) are intimately tied to the change.

I've done basic multilib-enabled builds but more testing welcome.  I'd say that
in general multilib problems this exposes are in fact problems with the recipe:
for example GConf should install the binaries once and libraries in each libdir.

Ross

[1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html
[2] https://www.gnu.org/prep/standards/html_node/Directory-Variables.html



             reply	other threads:[~2015-06-23 14:35 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-23 14:30 Ross Burton [this message]
2015-06-23 14:30 ` [PATCH 1/6] eglibc: WIP fix paths for libexec Ross Burton
2015-06-23 14:30 ` [PATCH 2/6] neard: remove libexec hacks Ross Burton
2015-06-23 14:30 ` [PATCH 3/6] bitbake: set libexecdir to prefix/libexec Ross Burton
2015-06-23 14:30 ` [PATCH 4/6] bluez5: fix lib/libexecdir confusion Ross Burton
2015-06-23 14:30 ` [PATCH 5/6] weston: fix libdir/libexecdir confusion Ross Burton
2015-06-23 14:30 ` [PATCH 6/6] sudo: " Ross Burton
2015-06-23 14:47 ` [RFC] Move libexecdir to $prefix/libexec Burton, Ross
2015-06-23 14:47   ` Burton, Ross
2015-07-15 20:49 ` Burton, Ross
2015-07-15 20:49   ` Burton, Ross

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=1435069807-13557-1-git-send-email-ross.burton@intel.com \
    --to=ross.burton@intel.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.