Skip to content
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

Closed
wants to merge 2 commits into from
Closed

RFC: Filetriggers #1893

wants to merge 2 commits into from

Conversation

keszybz
Copy link
Member

@keszybz keszybz commented Nov 15, 2015

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.

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
Copy link
Contributor

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?

Copy link
Member Author

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.

@arvidjaar
Copy link
Contributor

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)?

@keszybz
Copy link
Member Author

keszybz commented Nov 15, 2015

Are filetriggers universally supported?

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.

Does it mean ldconfig will be run when unit is installed (because path /usr/lib/systemd/system/my.unit obviously starts with /usr/lib)?

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).

@keszybz
Copy link
Member Author

keszybz commented Nov 15, 2015

Note that in this form you will get at least two successive reloads because both in and out triggers will be run

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.

@poettering
Copy link
Member

Looks conceptually OK to me, but I am of course no RPM guru.

But before you merge this, please merge the two separate commits...

@keszybz
Copy link
Member Author

keszybz commented Nov 15, 2015

two modelines?

Yikes.

OK, time for v2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

None yet

3 participants