After a turbulent week I finally have some time for the hobby again. However, there is a hardware problem with my build machine. The CPU fan failed and for some reason the warning for it was disabled in the bios. I didn't notice it until the machine just crashed with an overheated CPU while compiling. Cost me some sstate cache and I have to get a replacement for the fan. I had done some tests with sysvinit and this commit before. So far it looks like busybox/sysvinit has no major problems with the change. However, it is of course possible that such an invasive change could affect workflows that I didn't think of or overlooked to change one or the other line.

In case the commit message gave the wrong impression, I would like to explain that it was not my intention to push a change here just because I like systemd. My logic was something like this:

Glib-2.0 uses ptest to ensure that /tmp is not a symlink. I am inclined to believe that this is intended and not a bug in the test. Based on this assumption, there are not many options. You could either make sure that no symlink is created for ptests, which I don't think is a good idea. Strictly speaking, this would undermine the test by creating a different environment for it than exists on the target. It would be more honest to simply ignore the test for that case.

So I thought it would be best to fulfill glibs needs and remove the /tmp symlink everywhere. That's when systemd came into play because I thought if you have to make such an invasive change anyway, you should first see how systemd would expect it.  That would be correct if you agree that systemd should set the default.

If not, I could also send a variant where only the /tmp symlink is replaced by a directory  that has a  mounted tmpfs but doesn't remove /var/volatile/tmp. That might be a bit less invasive, but we would have the problem that directory structure under sysvinit is fundamentally different from that under systemd. In any case, even with this approach, I couldn't 100% rule out that it could affect sysvinit/busybox or even systemd based images or one or the other workflow. But at least I tried my best not to break sysvinit.

If I need to run any specific tests I can do that as soon as my CPU cools down again

On Fri, Mar 17 2023 at 07:10:36 PM +0000, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
I think it would help to at least take this through a-full so we have a higher degree of knowledge in what breaks and what doesn˙t. 

I didn˙t look at the patch in detail and won˙t be able to for a few more days. We definitely need to understand how it affects other init systems, but it is totally doable, there is only a limited number of them and how they handle tmp directories and what they expect from them is tractable research. As long as no one expects RP to do that.

Alex

On Fri 17. Mar 2023 at 17.31, Markus Volk <f_l_k@t-online.de> wrote:
Am Fr, 17. Mär 2023 um 11:53:17 +0000 schrieb Richard Purdie <richard.purdie@linuxfoundation.org>:
It would help me if adverse effects are mentioned in commit messages. In this case I can spot it easily enough but I don't always know/spot all the issues.

It would be too harsh to say that I don't care about sysvinit. Of course, if something breaks as a result of this commit, I'm willing to take care of it if I can help. It's just that I don't personally use it, so I haven't identified any other issues that might be relevant to sysvinit. Other than the obvious that anything that would write directly to '/var/volatile/tmp' would break.
At least I checked that sysvinit images could still boot. I have successfully run core-image-ptest-glib-2.0 with this patch applied. If I knew of any problems with sysvinit I would have pointed them out, but unfortunately I have no further findings yet