On Tue, Dec 11, 2018 at 12:52 PM Pete Walter <walter.p...@yandex.com> wrote: > > > > 11.12.2018, 10:29, "Fabio Valentini" <decatho...@gmail.com>: > > On Tue, Dec 11, 2018 at 11:05 AM Pete Walter <walter.p...@yandex.com> wrote: > >> 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. > > Please don't call other people's opinions nonsense. > https://docs.fedoraproject.org/en-US/project/code-of-conduct/index.html
I apologize. I didn't mean to be rude, or say anything other than this: I think your statement doesn't reflect the way things currently work. > Anyway, I would say that openssl 1.1 upstream was never designed around > distro packaging in mind. They probably assumed that it's fine to have just > one version of their headers installed at one time ... which is not the case > if you need to work on a piece of software that uses the new API, and another > piece of software that uses the old API. Conflicting packages mean repeatedly > installing and uninstalling things in that case. Not what I'd call good > packaging. That has nothing to do with "good" or "bad" packaging. It's an upstream project's decision, and if the downstream packaging works around it, and all dependent packages have to be patched to support the downstream-patched version - now that's what I would call bad packaging (or a hack). > compat-openssl10-devel are just a distro hack to make it possible to _build_ > stuff in koji against the older API, but it makes it a pain for any developer > to use the headers (because of the conflict). I agree. That's why the compat package will probably be retired once all consumers have been ported to the newer version. > >> 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.) > > That's unrelated that the runtime libraries have symbol conflicts. We were > talking about -devel parallel installability. Unless 95% of all libraries change the way they are built, that's not going to happen - currently most projects I watch do something like this: - The library API changes, and a major version is released with ABI changes and an soname bump of the library. - Dependent packages are *just rebuilt* against new library versions if the APIs they called didn't change, and - only packages that used changed APIs are adapted to the new API, with no other changes. However, renaming the base library name (including headers, pkgconfig file, etc.) for every major release of a library would require code changes in *every* downstream project using the library, whether the APIs they called changed or not - and renders the (useful) concept <soname bump -> just rebuild> completely obsolete, too. > >> 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. I'm not arguing against "doing things right", but that's ultimately a decision the upstream project has to make, and has nothing to do with packaging. > > It's good design to allow broken installations and development > > environments? I'd argue not. > > Please don't move the goal posts. Symbol conflicts is a completely different > issue and conflicting -devel packages changes nothing there. If the library's base name doesn't change, the unversioned .so symlink will conflict between the -devel packages - because it determines the shared library the built project is linked with. I don't see a way around that - other than to throw sonames out the window, rename the library with every version, and have all consumers change their code and build systems every time. (I don't think that's sustainable, and probably library versions and sonames were originally introduced to fix just that.) > If the devel packages conflict, it just makes it so much harder to use Fedora > to actually develop software. It's fine for package building purposes, of > course, but actually developing stuff is what I enjoy doing on Fedora. > > Pete > _______________________________________________ > 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 _______________________________________________ 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
