Re: [OE-core] Issue: /var/tmp does not persist due to /var/volatile being tmpfs in fstab #scarthgap

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Tue, 2025-03-18 at 16:24 -0700, Vish via lists.openembedded.org wrote:
> Thanks for the reply. 
>  
> Do maintainers recognize this as an issue with having this as default
> option? There are chances that similar to us other devs/orgs are
> planning migration in phases to Scarthgap considering Kirkstone
> getting updates, so this could potentially become issue for others as
> well.

I recognise there is an issue when behaviours change. We can't change
this in that release now but I would happily see patches/updates to the
migration guide and release notes making the issue clear.

> We do have sizable amount of edge systems in production with various
> CI, and this change broke an important feature and took some time for
> us to find root cause.

Sorry it was a pain. If you are able to check the state of master
periodically, it may help head some of these kinds of issues off.

> I believe correcting is still a proper thing to do and can be planned
> during any releases.
> 
> Additional reference -
> 
> 
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s15.html 
>  
> Also, it would be good to know what scenarios were considered with
> this change, probably we are missing some context.

Traditionally, OpenEmbedded was used in resource constrained embedded
systems and all "tmp" space was transient, not persistent. This
configuration is in keeping with the project's history.

Our approach isn't entirely against FHS, it is just not quite what
other distros do in our default config. There are other areas we do
differ from FHS too.

On this specific one, we support two init systems and I think the
configuration was mismatched between the two and the configuration
options were hard to get right and not working in all cases. There were
various patches over the last few years trying to make the docs,
options and init systems match up and be configurable. I suspect
somewhere on the way things changed in a way that wasn't realised.

The project is crying out for maintainer and review help. We do the
best we can with what we have, like most open source projects. An
implication of this is that where patches are submitted and nobody
objects and I don't see/spot any problem with them, they can be merged
even if there is an issue we didn't realise. We do the best we can.

How we react when things are merged depends on the circumstances.
Scarthgap has been out for nearly a year so a major behaviour change is
not really an option now. Even for master, I think the situation is
relatively well understood and more consistent now so any change would
need to demonstrate that isn't the case and that a change would improve
things rather than further confuse people.

I don't know who you work for but if you are able to help support the
project through patch review, recipe maintenance or anything else that
be nice. Alternatively, project membership does give us funding which
allows us to help in a different way too if that is an option. If you
don't do any of these things...

Hope that helps give some of the context.

Cheers,

Richard