Robert Scheck

I also would like to see libmodulemd as an optional dependency, because only Fedora/RHEL seem to use modularity. Have there been any successful downstream efforts to hack it simply out...

…I fully agree with the need to build libdnf without libmodulemd optionally.

So, you're saying that building libdnf without libmodulemd support leads to loss of cross-distro compatibility? What would that mean in the end? Just that I'm not able to install modules...

…sounds still perfect for a niche distribution!

Given libbsd 0.11.x is finally [on the way](https://bodhi.fedoraproject.org/updates/?like=libbsd-0.11) to all active Fedora and EPEL branches, fixing the documentation is good enough for me.

I'm not sure how #5805 addresses the main concern. The merge request talks about "PostgreSQL v12+". But that still leaves open again whether this actually means PostgreSQL v12, v13, v14...

@bcl, may I kindly ask for your attention here? [Rename libusb packages and deprecate old API](https://fedoraproject.org/wiki/Changes/Rename_libusb_packages_and_deprecated_old_api) is on the list for Fedora 34…and I am not sure whether I would...

I experienced the same issue when packaging mod_maxminddb for Fedora and EPEL. The underlying issue is that the hardening compile-time flags are not properly passed through your Makefile etc. to...

https://fedoraproject.org/wiki/Changes/F31_Mass_Python_2_Package_Removal will sooner or later lead to MacroMilter removal in Fedora due to Python 2.x dependencies, given Python 2.x reaches finally EOL on 2020-01-01.

As per https://bugzilla.redhat.com/show_bug.cgi?id=1738083, the Python 3 support starts to get important. I'm currently investigating to ensure proper Python 3.6 (or later) dependencies on all relevant branches to avoid the needs...