I’m interested in developing a native libdnf5-snapper plugin to replace the current Actions plugin workaround, and I’m looking for potential collaborators or existing work.
Background:
The python3-dnf-plugin-snapper works great with dnf4 but is incompatible with dnf5’s C++ architecture
Current “solution” requires users to manually configure libdnf5-plugin-actions with shell scripts
This feels like a significant regression in user experience compared to the seamless dnf4 plugin
Why Actions plugin isn’t sufficient:
No proper error handling or logging integration
No configuration system for plugin-specific settings
Fragile shell-script based snapshot linking
Missing intelligent transaction state management
No support for selective package filtering (important packages vs. regular packages)
Users report issues like missing package descriptions in snapshots
My technical approach:
Native C++ libdnf5 plugin using direct libsnapper API integration (following current Fedora packaging guidelines for shared library usage)
Inspired by openSUSE’s proven zypper-plugin architecture rather than the legacy dnf4-plugin D-Bus approach
Intelligent package classification - mark kernel/systemd/glibc updates as “important” for better cleanup policies
Configurable package filtering via INI configuration (similar to openSUSE’s /etc/snapper/zypp-plugin.conf)
Robust error handling with proper fallback behavior
Full integration with libdnf5’s transaction hooks and logging systems
Why direct libsnapper API over D-Bus:
libdnf5 plugins run as root anyway (At least the action that triggers a transaction.)
More reliable than D-Bus (works even during system rescue scenarios)
Better performance and simpler error handling
Follows current Fedora packaging best practices for shared libraries
Consistent with how other system tools integrate with libsnapper
Development scope:
Core functionality achievable in ~3-5 days
Additional features (advanced configuration, package importance classification) could follow
The foundation is solid - the dnf4 plugin logic translates well to C++ with libsnapper
Questions:
Is anyone already working on this? I couldn’t locate existing libdnf5-snapper development
Would the community be interested in such a contribution?
Should this be maintained separately or integrated into existing plugin collections?
Any objections to the direct libsnapper approach vs. D-Bus integration?
I’m happy to either collaborate on existing work or lead this development if there’s community interest. This could bring Fedora’s snapshot integration up to par with openSUSE’s mature implementation.
A quick follow-up on my original post from a few months back. The native libdnf5-snapper plugin I proposed is now complete and has been running stable on my systems since late September.
I’d like to get this into the official repositories and I’m happy to maintain it going forward. That said, I’m coming from a different distribution and the Fedora packaging process is new territory for me.
From what I’ve read, the next steps would be setting up a COPR build, submitting a Review Request via Bugzilla, and finding a sponsor since I’m a new contributor.
A few questions:
Would anyone be willing to sponsor this package review? I’m prepared to work through feedback and learn how things are done here.
Any concerns with the technical approach I should sort out before submitting?
Would someone be interested in co-maintaining? I can handle the ongoing work, but having someone around who knows Fedora infrastructure better would be helpful.
If anyone wants to test before the formal review, grab it from the GitHub releases. Feedback welcome.
Right there, on the top, you have the intro on how to become a packager.
We use the Fedora mailing lists for these purposes. I recommend you join the devel list as soon as you apply to be a packager. You’ll find a sponsor there easily, I think.
As far as the review goes, any fedora packager can review it. I would, gladly, review your package when you create the bugzilla and ping me about it.
Looking over the code, can we have the configuration go through the DNF5 configuration system? That way it’s possible to have configuration in /usr so that packaged configuration is possible. I think @sfaulken may be interested in providing some feedback here too.
