On Tue, Dec 11, 2018 at 11:05 AM Pete Walter <[email protected]> wrote: > > 10.12.2018, 19:22, "Neal Gompa" <[email protected]>: > > On Mon, Dec 10, 2018 at 2:06 PM Kalev Lember <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
