Re: [Buildroot] [PATCH 0/4] systemd: sort out the conflict between var factory and tmpfiles (branch systemdify-var)

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Norbert, All,

On 2022-10-17 18:49 +0200, Norbert Lange spake thusly:
> Am Mo., 17. Okt. 2022 um 18:00 Uhr schrieb <yann.morin@orange.com>:
> > But so far, we do not have that technically better solution, so we need
> > to fix things that are arctually broken.
> I tried to bring that in for ages. Probably just have cooked up a patch instead.

Indeed, with a patch to look at, it is easier to discuss. I've seen the
files now, and indeed I remember I already saw something like that some
time ago...

I'll test it in our use-case @work tomorrow.

Ultimately, I wonder if your solution could be an alternative to the var
factory, rather than replace it.

> I consider managing patch-series time consuming, so I'd like to discuss
> the way this should be structured before.
> This could be one completely separate package for example, allowing
> different solutions.

I am not sure separate packages in the way to go.

If we were to do those various solutions in different pacakges, then
we'd have to make it easy for users to use a package from their
br2-external trees, which is not so nice.

Also, see below: we already have a package where it is interesting to
implement the systemd integration in Buildroot: skeleton-init-systemd.

> > initrd is a blockdevice in memory. The filesystem one puts in there can
> > be any filesystem that could be otherwise stored on another blockdevice.
> > initramfs is a filesystem in memory, like a tmpfs. The initramfs is
> > read-write.
> Ok, I am using those pretty much interchangeable,
> just some block you tell the bootloader to load, either cpio or filesystem.

They are not the same thing at all, and they are not interchangeable;
the underlying code is totally different.

[--SNIP--]
> > I'll be sure to do as unbiased a review as possible for your proposal
> > when I see it. ;-)
> Gonna take me few days. should be easy to test tough with the provided files,
> just throw them into the buildroot filesystem overlay.
> Helps if you make some assessment where they should fit. the
> systemd package is already bloated enough.

Yes, our systemd.mk is a bit bloated.

What I'd like to do, is that the systemd integration at the package
level is done in package/systemd/, while the choices we do in Buildroot,
like using a var factory, calling systemd-tmpfiles, or using an
overlayfs, etc... be done somewhere else.

We have the merged-usr at the init level, and that is handled in the
skeleton-init-systemd package, and the var factory is also handled
there, so I started moving more stuff in there, like the systemd-tmpfiles
call, because I don't see a better place.

So, if you don't have a better idea, skeleton-init-systemd would be
where we handle that.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot