Looking to collaborate on native libdnf5 snapper plugin development

Project Discussion
,
1

Hi Fedora Community!

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:

  1. Is anyone already working on this? I couldn’t locate existing libdnf5-snapper development
  2. Would the community be interested in such a contribution?
  3. Should this be maintained separately or integrated into existing plugin collections?
  4. 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.

Thanks for any guidance!

Environment:

  • Fedora 42 with Btrfs + Snapper setup
  • C++ development experience with system libraries
  • New to Fedora community but eager to contribute
3 Likes
2

Hi everyone,

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.

Where things stand

The implementation follows the approach I outlined originally: native C++ using direct libsnapper API integration, intelligent package classification, and proper error handling. I’ve been testing it extensively on both Fedora 42 and 43 without issues. The code is on GitHub at GitHub - Plenvorik/libdnf5-plugin-snapper: Automatic filesystem snapshots for DNF5 package transactions using Snapper, including pre-built packages for anyone who wants to try it.

Getting this into Fedora

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.

1 Like
3

Hello, Andre. Congratulations on the plugin. :slight_smile:

I’m just a humble Fedora packager and not very good at that. Take my reply with a full teaspoon of salt.

I’m sure you must’ve read the packaging guidelines: Fedora Packaging Guidelines :: Fedora Docs

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.