Le 13/06/2019 à 20:31, Adam Samalik a écrit :
> So, I'd like to discuss the libgit issue [1] [2] we're experiencing. With a
> help of a few people, I've put together this post to get us on common
> ground: https://communityblog.fedoraproject.org/modularity-vs-libgit/
>
> There are few ideas about solving the issue right now. But we might be able
> to think about better ways to deal with similar issues long-term. Let's do
> this!
IMHO, having library in modules is an error, this can only raise issues
Perhaps debian was right, and we should use a naming schema matching the
library ABI, so including the soname
libgit26-0.26.8
libgit27-0.27.8
libgit28-0.28.1
etc
Thanks to soname, library are perfect use case for parallel installation
of multiple versions.
I agree, this is a way better solution for libraries (where possible).
And thanks to range version, this can be describe for dependencies.
BuildRequires: (pkgconfig(libgit) >=26 with pkgconfig(libgit) <= 27)
Yes, this will means more packages, and more reviews, but having a new
review on a old library when soname change make sense.
Compat packages for existing libraries are already exempt from package review, so that's not an issue.
Of course, old versions have to be retired when no more used
This is already what's happening with versioned llvm, for example.
Modules are fine for applications.
Remi
P.S. yes compat_* name schema also works... but also consider it as a
bit ugly...
The Packaging Guidelines explicitly state that libfoo0, libfoo0.7 or libgit2_0.27 patterns should be used for compat package names. The compat-foo stuff is outdated.
Fabio