<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 24, 2013 at 3:40 PM, Otavio Salvador <span dir="ltr"><<a href="mailto:otavio@ossystems.com.br" target="_blank">otavio@ossystems.com.br</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Wed, Jul 24, 2013 at 7:34 PM, Chris Larson <<a href="mailto:clarson@kergoth.com">clarson@kergoth.com</a>> wrote:<br>
><br>
> On Wed, Jul 24, 2013 at 2:51 PM, Otavio Salvador <<a href="mailto:otavio@ossystems.com.br">otavio@ossystems.com.br</a>><br>
> wrote:<br>
>><br>
>> On Wed, Jul 24, 2013 at 3:54 PM, Chris Larson <<a href="mailto:clarson@kergoth.com">clarson@kergoth.com</a>> wrote:<br>
>> ...<br>
>> > The standalone systemd-tmpfiles recipe I've created has a fairly small<br>
>> > set<br>
>> > of dependencies: intltool-native, dbus, libcap. Given this, I'd like to<br>
>> > propose transitioning away from populate-volatiles to systemd-tmpfiles,<br>
>> > even<br>
>> > for non-systemd images. I think that the update-tmpfiles shell script<br>
>> > may be<br>
>> > of use in a transition, but before we even begin discussing a transition<br>
>> > path, I'd like to request comments on the notion of moving to it at all.<br>
>><br>
>> I think it shouldn't be hard to make an C app or script which could<br>
>> parse systemd-tmpfiles and use this for non-systemd systems. What do<br>
>> you think?<br>
><br>
><br>
> I considered this too, but systemd-tmpfiles supports quite a lot more than<br>
> volatiles, for example restoring selinux labels. Maybe that sounds fun to<br>
> you, but it sounded like more trouble than it was worth to me, given<br>
> systemd-tmpfiles can be used without systemd :) But yes, it's definitely<br>
> another option to consider.<br>
<br>
</div>Sorry, pressed the send button too fast ...<br>
<br>
I understand but I think we could solve the tmp files issue only;<br>
people using sysv are expected to solve all those other issues in<br>
another way so it is not a regression for them.</blockquote><div><br></div><div style>I think those other issues still apply to tmpfiles, just not about their creation alone :) </div></div><br>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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>
-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>