On Tue, Dec 11, 2018 at 11:05 AM Pete Walter <walter.pete@xxxxxxxxxx> wrote: > > 10.12.2018, 19:22, "Neal Gompa" <ngompa13@xxxxxxxxx>: > > On Mon, Dec 10, 2018 at 2:06 PM Kalev Lember <kalevlember@xxxxxxxxx> wrote: > >> On 12/10/2018 07:30 PM, Stephen Gallagher wrote: > >> > It is versioned, actually. The 1.x API is `pkconfig(modulemd)` and 2.x > >> > is `pkgconfig(modulemd-2.0)`. The source of the conflict between the > >> > two -devel subpackages is that they both want to own > >> > /usr/lib64/libmodulemd.so, symlinked to different objects. > >> > >> Perhaps it would then make sense to rename libmodulemd.so to > >> libmodulemd-2.so in 2.x, so they don't conflict? > > > > No. It's better that the development subpackages conflict. There's > > zero reason for them to be co-installable. Exactly. > Huh, better to conflict? That's just not true. Conflicting packages are a major hurdle that we should try to avoid if at all possible. If it's still possible to still change the design of the library (rename the .so file) then it certainly makes sense to do so. That's nonsense. Compat packages for older versions of the same library always conflict, on purpose. For an example, look at the compat-openssl10-devel and openssl-devel packages. Packages are developed and built against either one version or the other, and *never* both - and even so, they can't be linked with both versions simultaneously due to symbol conflicts. > Look at some well designed libraries, gtk2 and gtk3 for example that can exist in parallel and have -devel packages that don't conflict. gtk2/3 is a bad example. Those two packages provide two differently named libraries, not different versions of a library with the same name (libgtk-x11-2.0.so vs. libgtk-3.so). (Nevermind that the symbols conflict anyway and nothing can link against both, see the webkit2gtk3 / gtk2 plugin process mess.) > Of course, you could make an argument that it is different there because gtk has longer lifetime than libmodulemd, but it still makes sense to do things right if we can and not make packages unnecessarily conflict. It's just good design that way. It's good design to allow broken installations and development environments? I'd argue not. Fabio > Pete > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
