On Tue, Jul 29, 2025 at 9:43 AM Stephen Gallagher <sgall...@redhat.com> wrote: > > On Tue, Jul 29, 2025 at 4:54 AM Neal Gompa <ngomp...@gmail.com> wrote: > > > > On Tue, Jul 29, 2025 at 3:46 AM Zdenek Dohnal <zdoh...@redhat.com> wrote: > > > > > > Hi, > > > > > > per > > > https://fedoraproject.org/wiki/Changes/FoomaticRipRejectsUnknownValues > > > I've got feedback about turning RPM scriptlet into systemd service to > > > have the change applied even on immutable systems, like bootable > > > containers, Fedora CoreOS etc. > > > > > > Does anyone use such systemd service for upgrade tasks in their packages? > > > > > > Would you mind sharing the name of component which uses such service, so > > > I can check how it is supposed to look? > > > > > > > In general, it's a flawed way to approach the problem. > > > > If it was trivial to handle, it would probably be done by the programs > > themselves automatically. If it is not trivial to handle, it is not > > reasonable to use a systemd service to do it. > > > > That is a surprisingly naive thing to hear you say, because I know > you've been around for a long time.
As soon as I sent this, I re-read it and realized that this really comes across as condescending and I'm not entirely sure why I added it at all. Please accept my apology for the tone. I'm sorry. > Yes, it's *ideal* when the > application itself handles config migration automatically, but it's > hardly common. Most applications just ship a release note and usually > an updated default configuration and that's it. > > > > Delayed execution of scriptlets by migrating them to systemd units > > also creates problems because it de-links the execution from the > > transaction. This means that the risk of breakage goes up depending on > > things happening on the system between transaction execution and the > > reboot. > > It also means that the risk of breakage becomes limited to the single > application instead of risking aborting a DNF transaction and leaving > the system in an unbootable state. > > I'm also not sure what you mean by " the risk of breakage goes up > depending on things happening on the system between transaction > execution and the reboot." unless you mean that people are writing > these systemd units to try to fire after the transaction completes (in > the same boot) instead of making the new upgrade unit a prerequisite > for starting the service the next time it gets loaded. > > Or are you worried about the user performing manual edits during this > timeframe? I'm not really sure what situation you're concerned about > here. > > > My previous attempts at doing stuff like this (like rpmdb-rebuild and > > rpmdb-migrate) wound up being fraught with peril (and my fixes never > > were merged, resulting in somewhat broken migrations for years). If > > something needs to be executed as part of the transaction, it just > > needs to happen there. If it can be done outside of the transaction, > > it should be handled as part of the program or service itself, and not > > as a separate systemd unit. -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
