From fedd9088b3142ea1141708d53aa00ed783e11ed8 Mon Sep 17 00:00:00 2001 From: Jonathan Lebon Date: Feb 15 2024 04:47:06 +0000 Subject: Scriptlets: recommend against writing to `/var` In the rpm-ostree variants of Fedora, we've hit many times over the years instances of packages wanting to perform migrations/cleanups as part of e.g. their `%post` scripts. Such scripts do not work in those variants because they run at compose time on the build server and not on client systems (rpm-ostree also support layering RPMs on the client, but by design the same limitations apply there). As a result, either the migration never takes place on those variants, or the scriptlet fails to run and breaks the compose (because rpm-ostree runs scriptlets with a read-only `/var`). We (the Fedora CoreOS Working Group) would like to submit a Change proposal that will as a first pass recommend against scriptlets writing to `/var`.[[1]] As prescribed in the Changes policy[[2]], this is a draft PR with the suggested change for review before actually submitting a proposal. (An eventual goal would be to forbid it completely. That could be done as part of this Change or a follow-up Change based on discussions with the community and FESCo.) [1]: https://github.com/coreos/fedora-coreos-tracker/issues/1067 [2]: https://docs.fedoraproject.org/en-US/program_management/changes_policy/#_fedora_packaging_committee --- diff --git a/guidelines/modules/ROOT/pages/Scriptlets.adoc b/guidelines/modules/ROOT/pages/Scriptlets.adoc index 9f9cfde..b23a34d 100644 --- a/guidelines/modules/ROOT/pages/Scriptlets.adoc +++ b/guidelines/modules/ROOT/pages/Scriptlets.adoc @@ -198,6 +198,36 @@ in the same manner even if they already have a `+%pre+` or `+%post+` defined. Of course, in the above situation it is better to use RPM file triggers if at all possible. +=== Modifying /var + +Apart from `+/var/tmp+` and the aforementioned `+/var/lib/rpm-state/+` +directories, RPM scriptlets SHOULD NOT try to read from or write to `+/var+`. + +==== Rationale + +Image-based compose and update systems, such as OSTree, Image Builder, and +container images run RPM scriptlets at compose time, e.g. on a build server. +This means that the scripts don't have the opportunity to directly affect system +state in `+/var+`. + +On an OSTree system for example, a strong emphasis is placed on upgrades being +offline, which means that an upgrade simply cannot affect the system in any +visible way until the user actually decides to reboot into the new update. + +==== Alternatives + +The common motivation for wanting to modify system state is to perform some sort +of migration, cleanup, or to initialize some state. The common ways to address +these in an image-friendly manner are: + +1. A `+tmpfiles.d+` dropin: to initialize state in `/var` at boot time. +2. A systemd service: to run imperative code at boot time, ordered before the +service that depends on said code having executed. For one-time migrations, you +likely want to use e.g. a stamp file combined with `+ConditionPathExists=+`. +3. Integrating into the dependent service: have the migration or cleanup be +carried out by the very service that depends on it. This is often the simplest +on the packaging side, but likely requires the upstream to support it. + == Snippets Some scriptlets to use in specific situations.