libgit2 1.5.x in rawhide with compat packages for 1.3.x and 1.4.x

[Josh Stone]

On 2/3/23 8:04 AM, Pete Walter wrote:
>  I took over libgit2 from Igor when he gave up all his packages and
> have
>  since tried to get it up to date. libgit2 is a bit special because it
>  bumps soname every once in a while and then other packages often fail to
>  rebuild against the new version both because of libgit2 API changes and
>  because they are FTBFS due to unrelated issues (hi new gcc). libgit2 is
>  also network facing and due to this has a high number of security issues
>  so it is very important to keep it up to date.
>   
>  I think I have a good plan now how to keep it up to date without too
>  much disruption and it is as follows:
>   
>  Update libgit2 to new version in rawhide as soon as it is released. At
>  the same time, create a compat package for the old API and add it to
>  rawhide. Keep the old API compat package in rawhide for 6 months or as
>  long as it takes for everything to switch over to the latest version.
>   
>  Today, we have 3 versions in rawhide (libgit2 was updated from 1.3.x to
>  1.4.x and then 1.5.x over the last month and the compat packages were
>  added today):
>   
>  libgit2 package with version 1.5.1 (security supported still from upstream)
>  libgit2_1.4 package with version 1.4.5 (security supported still from
>  upstream)
>  libgit2_1.3 package with version 1.3.2 (EOL upstream) 
Thank you for taking care of this! I've had rust (subpkg cargo) using
its own bundled copy due to the lack of updates, but I'll happily flip
that back. Since Rust bootstraps itself, it's important to always have
the old version working while I rebuild to a new version, but the compat
scheme should be fine -- we do the same for LLVM libs.

(Note regarding that 1.5.1 security issue, cargo fixed it independently
in 1.66.1, so there's no bundling worry about that one.)

>  I intend to retire libgit2_1.3 as soon as git-time-metric
>  (https://bugzilla.redhat.com/show_bug.cgi?id=2162852
>  <https://bugzilla.redhat.com/show_bug.cgi?id=2162852>) and
>  golang-github-libgit2-git2go
>  (https://bugzilla.redhat.com/show_bug.cgi?id=2152113
>  <https://bugzilla.redhat.com/show_bug.cgi?id=2152113)>) are fixed.
>  I intend to retire libgit2_1.4 as soon as julia
>  (https://bugzilla.redhat.com/show_bug.cgi?id=2165534
>  <https://bugzilla.redhat.com/show_bug.cgi?id=2165534>) and
>  rpm-git-tag-sort (https://bugzilla.redhat.com/show_bug.cgi?id=2165535
>  <https://bugzilla.redhat.com/show_bug.cgi?id=2165535>) are fixed.
>   
>  The rest of the dependencies are already rebuilt to use libgit2.
>   
>  I think this kind of compat package system could even allow updating
>  libgit2 to latest versions in stable Fedora branches and in EPEL. I want
>  to test this out in rawhide first though and see if it works well enough.
>   
>  Pete
>  
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Fabio Valentini]

On Fri, Feb 3, 2023 at 5:05 PM Pete Walter <walter.pete(a)yandex.com&gt; wrote:
>  Today, we have 3 versions in rawhide (libgit2 was updated from 1.3.x to 1.4.x and then
> 1.5.x over the last month and the compat packages were added today):
>
>  libgit2 package with version 1.5.1 (security supported still from upstream)
>  libgit2_1.4 package with version 1.4.5 (security supported still from upstream)
>  libgit2_1.3 package with version 1.3.2 (EOL upstream) 
Thank you for working on this!

It would be great if libgit2 updates and compat packages could be
pushed to stable branches as well. It would allow me to un-vendor
libgit2 from the libgit2 Rust bindings, which suffer from the same
problems as most other libgit2 consumers (either libgit2 in Fedora is
too new, or too old), and the bindings are only ever compatible with
one 1.x branch at a time due to subtle API and / or ABI changes ...
(honestly I was kind of hoping that the 1.0.0 release of libgit2 would
mark an era with more stability, but apparently the upstream project
just released 1.0.0 and kept on breaking things with minor releases
for fun).

We would probably need to adapt consumers of libgit2 to specify which
1.x of libgit2 they want to build against before this can be pushed to
stable branches though - otherwise many will just pull in the most
recent one and start to fail to build (which wouldn't be good in
stable branches).

Fabio