-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Filetriggers #1893
RFC: Filetriggers #1893
Conversation
This uses new functionality added in rpm 4.13. Instead of doing one daemon-reload per packages, we do just one or two (When both installing and uninstalling packages, we do two. Unfortunately this also includes the common case of upgrades. When only installing or when only installing, we do just one.) New file triggers.systemd can be built, but the contents have to be copied into the rpm spec file by hand. Using %{load} does not seem to work. It can serve as documentation.
|
||
# The contents of this are an example to be copied into systemd.spec. | ||
|
||
%transfiletriggerin -- @systemunitdir@ /etc/systemd/system |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why /etc/systemd? Package are not supposed to install anything there, are not they?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a "better safe than sorry" consideration. Some packages install commented-out files in there (systemd itself, sssd, tlp). In principle those files shouldn't matter, but I thought it would be simpler to also react to that than to prove that we don't ever need to. Anyway, since packages rarely install anything there, triggering on /etc is not costly.
Are filetriggers universally supported (they were not last time I looked)? Note that in this form you will get at least two successive reloads because both in and out triggers will be run. This is inherent problem in this implementation. If my memory serves me right, Mandrake used single trigger type without this distinction. This makes more sense for those use cases when triggers are used - we do not really care whether files are added or removed, we just care that directory content (or file set) has changed. Also "path starting with" in trigger description in rather ambiguous. Does it mean ldconfig will be run when unit is installed (because path /usr/lib/systemd/system/my.unit obviously starts with /usr/lib)? |
They are in the latest rpm upstream, so I presume that sooner or later they will be available anywhere. We require latest util-linux and a bunch of other stuff; this is no different.
The trigger script will be run. It could be smart enough to filter out non-library files. I don't know how the implementation looks (actually I think that in Fedora we don't even have a ldconfig filetrigger yet). |
Yes. But I don't think there's a way around this in the current implementation. %transfiletriggerun is only run on upgrade or uninstall, %transfiletriggerin is only run on installation or upgrade. We need to cover all three cases. |
Looks conceptually OK to me, but I am of course no RPM guru. But before you merge this, please merge the two separate commits... |
Yikes. OK, time for v2. |
Fedora change page: https://fedoraproject.org/wiki/Changes/systemd_file_triggers
I'm putting this out here for comments. It appears to work fine, but there're still some open questions, at least https://bugzilla.redhat.com/show_bug.cgi?id=1282115.