[OE-core] Why is systemd installed to / (was: [yocto] Export bitbake variables between recipes)

[Peter Kjellerstedt]

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> Mark Hatle
> Sent: den 2 december 2014 19:45
> To: openembedded-core at lists.openembedded.org
> Subject: Re: [OE-core] Why is systemd installed to / (was: [yocto]
> Export bitbake variables between recipes)
> 
> 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 at yoctoproject.org [mailto:yocto-
> >> bounces at yoctoproject.org] On Behalf Of Paul Eggleton
> >> Sent: den 2 december 2014 15:07
> >> To: Fabrice Coulon
> >> Cc: yocto at 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.

Hmm, ok.

> If you set it to /usr, then technically you are violating the FHS, as
> you now require /usr in order to boot the system.

Ok. We have never split / and /usr in our products so that thought 
did not occur to me.

> 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?

In the specific case it was a systemd unit file that wants to do 
ExecStartPost=/usr/bin/systemctl kill --signal HUP rsyslog.service
and since paths in unit files must be absolute this caused problems 
for us when building with Poky since then systemctl is in /bin, but 
when building with our old build system it is in /usr/bin...

Now it is no major problem to fix the specific unit file, because we 
can just do ExecStartPost=/bin/sh -c "systemctl kill ...", but the 
difference between our two build systems has caused us quite a lot  
of extra work.

> > 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'.

Speaking of Fedora, would an official image feature, e.g., "unified-fs", 
be acceptable for OE-Core that sets up the file system with /bin, /sbin 
and /lib* as links to their /usr counterparts? That would alleviate our 
problems with the differences in how systemd is installed.

> (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

//Peter