Re: [Buildroot] [PATCH 0/6 v3] systemd: sort out the conflict between var factory and tmpfiles

From: "Yann E. MORIN" <yann.morin.1998@free.fr>
To: Norbert Lange <nolange79@gmail.com>
Cc: "Jérémy Rosen" <jeremy.rosen@smile.fr>,
	"Romain Naour" <romain.naour@smile.fr>,
	yann.morin@orange.com, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 0/6 v3] systemd: sort out the conflict between var factory and tmpfiles
Date: Sun, 6 Nov 2022 17:49:41 +0100	[thread overview]
Message-ID: <20221106164940.GC3918838@scaer> (raw)
In-Reply-To: <CADYdroO7gJybDDV+oBqwOEHyHptKcdqnetBKTQ-tVHQkHUAUuQ@mail.gmail.com>

Norbert, All,

On 2022-11-06 17:21 +0100, Norbert Lange spake thusly:
> Am Di., 18. Okt. 2022 um 21:43 Uhr schrieb <yann.morin@orange.com>:
[--SNIP--]
> > ----------------------------------------------------------------
> > Yann E. MORIN (6):
> >       package/skeleton-systemd: move /var factory tmpfiles out of /etc
> >       package/skeleton-systemd: systemd-ify mounting /var tmpfs with ro rootfs
> >       package/skeleton-systemd: host the tmpfiles preparation script
> >       system: add options for /var factory and tmpfiles pre-seed
> >       system: introduce a choice for /var management
> >       system: add option to use an overlayfs on /var on a r/o root w/ systemd
> 
> you did not cc me for
> [PATCH 5/6 v3] system: introduce a choice for /var management

Woops, that is definitely an oversight, as I did plan on having you in
cc of all changes for you to review. Sorry for the mishap.

> I would choose the world NONE instead of CUSTOM,
> as that is what buildroot does with /var.

I am not too strongly set on using CUSTOM, so NONE is OKish...

> Later we could offer CUSTOM by for ex. only providing a var.mount
> file, that expects a user-specific mount or similar.

I am not sure I can see how that would work...

Were you thinking of something like:

    [Mount]
    EnvironmentFile=-/etc/default/fs.var
    Where=/var
    What=$VAR_DEVICE
    Type=$VAR_TYPE
    Options=$VAR_OPTIONS

But then, would it not be easier to just provide a drop-in to override
those? What would be the advantage for us to provide a template to begin
with, leaving users to provide thei full var.mount?

And that also leaves the question of how that /var would get populated.

> +config BR2_INIT_SYSTEMD_VAR_NONE
> + bool "do nothing"
> + help
> +  Choose this if you have custom dispositions (like a
> +  post-build, fakeroot script, systemd units, or initramfs)
> +  that prepare /var to be writable on a read-only rootfs.

Actually, "do nothing" is a bit misleading, as users with custom setups
actualyl *do* something, it's just something else that is not listed in
the prompt.

But you are right, that the choice for the init system has a "None"
entry with a _NONE suffixed option, so for consistency, that is probably
good to use _NONE here too.

> but take my
> 
> Acked-by: Norbert Lange <nolange79@gmail.com>

Great! :-)

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