From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Why is systemd installed to / (was: [yocto] Export bitbake variables between recipes)
Date: Tue, 2 Dec 2014 12:44:57 -0600 [thread overview]
Message-ID: <547E08A9.2090500@windriver.com> (raw)
In-Reply-To: <A612847CFE53224C91B23E3A5B48BAC7ACF18D3E7B@xmail3.se.axis.com>
On 12/2/14, 12:27 PM, Peter Kjellerstedt wrote:
> [ I am moving this discussion to the OE-core list as I believe
> that is where it belongs. ]
>
>> -----Original Message-----
>> From: yocto-bounces@yoctoproject.org [mailto:yocto-
>> bounces@yoctoproject.org] On Behalf Of Paul Eggleton
>> Sent: den 2 december 2014 15:07
>> To: Fabrice Coulon
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] Export bitbake variables between recipes
>>
>> Hi Fabrice,
>>
>> On Tuesday 02 December 2014 14:07:40 Fabrice Coulon wrote:
>>> Is it possible to export one bitbake variable from one recipe
>>> and make it available from inside another recipe? For example:
>>> we want to export from our systemd_%.bbappend where the
>>> systemctl command has been installed, in order to, from another
>>> recipe depending on systemd, refer to the absolute path where
>>> systemctl was installed. Any ideas or suggestions on how to do
>>> that?
>>
>> There's no mechanism to do this, no. The only way for this kind of
>> thing to work is for it to be specified at the configuration level
>> (e.g. ${bindir} points to the subdirectory /usr/bin and this variable
>> would be used both when choosing where the executable should be
>> installed and finding it later - this would typically be how this
>> kind of problem would be solved since it would be unusual to have
>> systemctl installed somewhere other than ${bindir}).
>
> Actually, since the systemd recipe in Poky is configured in an
> extremely weird way (using --with-rootprefix=${base_prefix} and
> --with-rootlib=${base_libdir}), systemctl actually ends up in
> ${base_bindir} rather than ${bindir}. And this is the whole reason
> for our troubles since everything else we had prior to switching
> to Poky expected systemd to be installed in /usr...
Because we support the split between / and /usr for embedded systems with
multiple partitions/disks.
If you set it to /usr, then technically you are violating the FHS, as you now
require /usr in order to boot the system.
What programs are expecting these things in a specific path? Why aren't they
either using the PATH, or using a similar configuration mechanism via the recipes?
> Can anyone please explain why OE-core installs systemd to / rather
> than /usr? Because I have traced the recipe all the way back to its
> introduction in OE classic, and I cannot find any rationale for
> this odd decision. And it is extra weird given the systemd authors'
> agenda that everything should be in /usr (and /etc)...
It's only strange compared to Fedora. We're not Fedora.. and I've got systems
that need to boot from a small '/' before mounting '/usr'.
(In prior discussions we've made the decision to not fix every library or
application, but there is a warning you can enable that will show you what
libraries and applications live in '/' but have obvious linkage to '/usr'.)
>> (Another alternative is pkg-config, but I don't think that really
>> applies in this situation.)
>
> Nope.
>
>> Cheers,
>> Paul
>>
>> --
>>
>> Paul Eggleton
>> Intel Open Source Technology Centre
>
> //Peter
>
>
next prev parent reply other threads:[~2014-12-02 18:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-02 18:27 Why is systemd installed to / (was: [yocto] Export bitbake variables between recipes) Peter Kjellerstedt
2014-12-02 18:44 ` Mark Hatle [this message]
2014-12-03 15:36 ` Peter Kjellerstedt
2014-12-03 15:46 ` Mark Hatle
2014-12-04 13:34 ` Peter Kjellerstedt
2014-12-05 3:00 ` ChenQi
2014-12-05 3:46 ` Mark Hatle
2014-12-08 7:44 ` Adrian Freihofer
2014-12-08 13:37 ` Peter Kjellerstedt
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=547E08A9.2090500@windriver.com \
--to=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.