Release dnf5-5.2.0.0

[kontura]

Since we need to do API and ABI changes we will have to make a new major version release update.

This issue should track all the required/planned changes:

• Improve ABI stability #1025
• builddep: Don't try to expand globs in pkg specs #1085
• Argument parser: support repeated positional args, use p_impl, no inline methods #1087
• Add a method accepting std::string for filter_provides() #1216
• dnfdaemon Missing end transaction signal #1189
• Rework output header files #1072
• Drop deprecated API
  • Hide/Remove deprecated methods #1294
  • Hide libdnf5::repo::Repo::load() for dnf5-5.2.0.0 #1322

Follow-ups:

• Re-enable clang builds after API changes #1421

[voxik]

"Dnf5-6.0.0" sorry, I can't help, but this won't stop fascinating me.

[j-mracek]

I am proposing to add use_glob{true} to ResolveSpecSettings. Such a change will brake ABI.

[Conan-Kudo]

"Dnf5-6.0.0" sorry, I can't help, but this won't stop fascinating me.

We should have just renamed the old project to "dnf4" and kept calling this "dnf" but here we are. :)

[kontura]

We are also considering changing the versioning to add one more number and keep the 5.
So the new breaking version would be dnf5-5.2.0.0.

The nevras still do compare correctly: dnf5-5.2.0.0 > dnf5-5.1.0.

[jan-kolarik]

OK, I believe we can proceed with merging this to main.

[Conan-Kudo]

Do you think we have sufficient API coverage for me to implement a PackageKit backend using libdnf5 based on what we have for the current dnf backend? https://github.com/PackageKit/PackageKit/tree/main/backends/dnf

[jan-kolarik]

Do you think we have sufficient API coverage for me to implement a PackageKit backend using libdnf5 based on what we have for the current dnf backend? https://github.com/PackageKit/PackageKit/tree/main/backends/dnf

I believe so, but I'll try to go through it this week to verify. However, I'm curious and a bit confused because I thought PackageKit is already only in maintenance mode, and new plugins for package manager frontends like GNOME Software, KDE, dnfdragora, etc., are now being developed using the dnf5daemon API.

[jan-kolarik]

Do you think we have sufficient API coverage for me to implement a PackageKit backend using libdnf5 based on what we have for the current dnf backend? https://github.com/PackageKit/PackageKit/tree/main/backends/dnf

So, I went through the existing PackageKit backend for dnf, and I didn't find any features lacking in dnf5. However, it's possible I overlooked something as the codebase is pretty extensive. In any case, if you encounter any challenges implementing specific use cases with the DNF5 API, don't hesitate to reach out. 🙂

[Conan-Kudo]

However, I'm curious and a bit confused because I thought PackageKit is already only in maintenance mode

"Maintenance mode" doesn't mean nobody works on it. That doesn't mean it's dead. It means there are currently no new features planned (nobody has asked for any either).

new plugins for package manager frontends like GNOME Software, KDE, dnfdragora, etc., are now being developed using the dnf5daemon API.

Only dnfdragora is using dnf5daemon because it previously used dnfdaemon. Everyone else still uses PackageKit.