I think the best option is to create non-modular compat packages. In my opinion, modularity makes sense for end user applications, but I'm not sure what benefits it has for libraries. Libraries tend to work well as compat packages, so I implemented this in copr to try it out.
* https://copr.fedorainfracloud.org/coprs/carlwgeorge/parallel-libgit2/ * https://copr-be.cloud.fedoraproject.org/results/carlwgeorge/parallel-libgit2/fedora-rawhide-x86_64/00935643-libgit2_0.26/libgit2_0.26.spec * https://copr-be.cloud.fedoraproject.org/results/carlwgeorge/parallel-libgit2/fedora-rawhide-x86_64/00935642-libgit2_0.27/libgit2_0.27.spec This copr allows the following non-modular packages to be installed at the same time: * Rawhide * libgit2 0.28.2 * libgit2_0.27 0.27.8 * libgit2_0.26 0.26.8 * Fedora 30 * libgit2 0.27.8 * libgit2_0.26 0.26.8 These packages follow the current naming and conflict packaging guidelines. * https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple * https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_compat_package_conflicts If I'm missing anything about the benefits of a modular libgit2 help me understand. Given the current issues, this seems like a reasonable solution. If other agree, I'm happy to submit these compat packages for review. Carl George Rackspace _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
