[OE-core] RFC: meta-ro-rootfs approach and volatiles vs tmpfiles.d

[Chris Larson]

On Wed, Jul 24, 2013 at 3:40 PM, Otavio Salvador <otavio at ossystems.com.br>wrote:

> On Wed, Jul 24, 2013 at 7:34 PM, Chris Larson <clarson at kergoth.com> wrote:
> >
> > On Wed, Jul 24, 2013 at 2:51 PM, Otavio Salvador <
> otavio at ossystems.com.br>
> > wrote:
> >>
> >> On Wed, Jul 24, 2013 at 3:54 PM, Chris Larson <clarson at kergoth.com>
> wrote:
> >> ...
> >> > The standalone systemd-tmpfiles recipe I've created has a fairly small
> >> > set
> >> > of dependencies: intltool-native, dbus, libcap. Given this, I'd like
> to
> >> > propose transitioning away from populate-volatiles to
> systemd-tmpfiles,
> >> > even
> >> > for non-systemd images. I think that the update-tmpfiles shell script
> >> > may be
> >> > of use in a transition, but before we even begin discussing a
> transition
> >> > path, I'd like to request comments on the notion of moving to it at
> all.
> >>
> >> I think it shouldn't be hard to make an C app or script which could
> >> parse systemd-tmpfiles and use this for non-systemd systems. What do
> >> you think?
> >
> >
> > I considered this too, but systemd-tmpfiles supports quite a lot more
> than
> > volatiles, for example restoring selinux labels. Maybe that sounds fun to
> > you, but it sounded like more trouble than it was worth to me, given
> > systemd-tmpfiles can be used without systemd :) But yes, it's definitely
> > another option to consider.
>
> Sorry, pressed the send button too fast ...
>
> I understand but I think we could solve the tmp files issue only;
> people using sysv are expected to solve all those other issues in
> another way so it is not a regression for them.


I think those other issues still apply to tmpfiles, just not about their
creation alone :)

Assuming others have other ways of handling that, it does bother me a
little still duplicating that information between tmpfiles config and
whatever that 'another way' was, but it would definitely be a step in the
right direction.

Using a single config file but different implementations would absolutely
be an improvement over the current handling, and would be less invasive,
and wouldn't add the potential additional deps brought in by
systemd-tmpfiles. It's a good idea, and I'd be curious to hear what others
think about this option vs using systemd-tmpfiles itself.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20130724/1916974f/attachment-0002.html>