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

Peter Kjellerstedt peter.kjellerstedt at axis.com
Mon Dec 8 13:37:44 UTC 2014


> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf Of
> ChenQi
> Sent: den 5 december 2014 04:01
> 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/04/2014 09:34 PM, Peter Kjellerstedt wrote:
> >> -----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 3 december 2014 16:47
> >> To: Peter Kjellerstedt; openembedded-core at lists.openembedded.org
> >> Subject: Re: [OE-core] Why is systemd installed to / (was: [yocto]
> >> Export bitbake variables between recipes)
> >>
> >> On 12/3/14, 9:36 AM, Peter Kjellerstedt wrote:
> >>>>> 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.
> >> The system permits developers to set the paths for the various
> pieces.
> >> To get a Fedora like unified filesystem, you could do something like:
> >>
> >> * provide your own fs-perms.txt:
> > I had not noticed fs-perms.txt before. And it seems easy enough
> > to extend via the FILESYSTEMS_PERMS_TABLES variable. :)
> >
> >> /usr/bin	link	${base_bindir}
> >> /usr/sbin	link	${base_sbindir}
> >> /usr/lib	link	${base_libdir}
> >>
> >> Then in your local.conf:
> >>
> >> bindir = "${base_bindir}"
> >> sbindir = "${base_sbindir}"
> >> libdir = "${base_libdir}"
> > I think you mean the opposite, i.e., that /bin should be a
> > link to ${bindir} and ${base_bindir} should be set to ${bindir},
> > but I get your point.
> >
> >> This will result in /usr/bin, sbin and lib being linked to /bin,
> >> /sbin, /lib -- and all of the package produced for your
> >> configuration will only reference '/'.
> >>
> >> This isn't that unusual of a configuration from what I've been told.
> > Which is why I think it warrants an official distro feature (an
> > image feature, as I originally suggested, will of course not do
> > if it is done the way you suggest since the packages' contents
> > are modified). That way people would not have to invent the wheel
> > over and over again (and somehow find out that there is such a
> > thing as fs-perms.txt which up until now had eluded me).
> >
> >> --Mark
> > //Peter
> >
> 
> Hi Peter,
> 
> It's easy to link /usr/bin to /bin, /usr/sbin to /sbin and make things
> work in OE.
> But if we want the opposite to work, we might need several additional
> patches to OE.
> 
> Several days ago, I tried to do /usr merge in OE (like what Fedora and
> Arch does). It turned out that we need to patch several packages to
> make things work.
> 
> (I haven't sent out the patches because it's just some initial
> investigation and I'm not sure if people want this feature or not.)
> 
> If you want this feature in OE, please open a bug/enhancement in
> bugzilla https://bugzilla.yoctoproject.org/ to see if the community
> wants it or not.
> 
> Regards,
> Chen Qi

I have created a ticket for this now: 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=7040

//Peter




More information about the Openembedded-core mailing list