libgit2 0.24.1

[ben-willmore]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same formula update/change?
• Does your submission pass brew audit --strict --online <formula> (where <formula> is the name of the formula you're submitting)?
• Have you built your formula locally prior to submission with brew install <formula>?

[UniqMartin]

Out CI build failed because there are two formulae that no longer work after this update, which seems to involve a change to the install name of libgit2. Please bump the revisions of gitg and gnome-builder (use a commit subject of <formula>: revision for libgit2, one commit per formula) and push the additional commits. This should make the next build succeed. Thanks!

[UniqMartin]

After some digging around I have to add, there's also PR #267 that includes updates for gitg and gnome-builder. It is quite possible that one or both of them are not yet compatible with libgit2 0.24.x, so this PR might need to wait until #267 is merged.

(If you're curious, make sure to check out that PR and what it links to. It might also be worthwhile to search for previous libgit2 PRs in the old Homebrew/legacy-homebrew repository—seems you're not the first one to try to update libgit2 to the 0.24.x series.)

[ben-willmore]

Thank for the feedback.

Bumping the revision number on gitg reveals that it specifies libgit2-glib-1.0 < 0.24.0 (see below), so, as you suggested, I guess this is not going to work until the big Gnome update (#267) is merged.

==> ./configure --disable-silent-rules --prefix=/usr/local/Cellar/gitg/3.18.0_1 
Last 15 lines from /Users/ben/Library/Logs/Homebrew/gitg/01.configure:
    webkit2gtk-4.0 >= WEBKITGTK_REQUIRED_VERSION
    settings-desktop-schemas
    gee-0.8
    json-glib-1.0
    libsecret-1
) were not met:

Requested 'libgit2-glib-1.0 < 0.24.0' but version of libgit2-glib is 0.24.0

[UniqMartin]

TL;DR Blocked by #267.

Thanks for giving it a try anyway! I guess we'll have to wait (hopefully not too long). Let's keep this open so other will see and not duplicate your work. I'll try to get back to this when it's ready, but feel free to ping me if I don't notice immediately.

[calvn]

Can Formula/libgit2.rb be updated at least since it doesn't depend on the GNOME update?

[UniqMartin]

Can Formula/libgit2.rb be updated at least since it doesn't depend on the GNOME update?

Are you sure this can be safely done without breaking formulae that depend on libgit2? Unfortunately, I'm not very familiar with this library. cc @tschoonj as the driving force behind the GNOME update. Can you comment on whether the libgit2 update can be safely decoupled from the GNOME update? (There seems to be sufficient demand that it would be a good thing to do, if possible.)

[tschoonj]

No it cannot: it will force gitg and gnome-builder to be updated as well, which in turn will drag in gtk+3 3.20...

If you really need libgit2 and libgit2-glib, and don't want to wait for the GTK people to fix their releases, then the only solution is to boneyard gitg and gnome-builder for now.

[UniqMartin]

I don't think temporarily boneyarding gitg and gnome-builder is the solution here. We're currently pondering ideas how we can provide multiple versions of a formula to simplify transitions like these, while still giving users access to the latest version. Essentially, we want to make it possible for formulae that depend on certain libraries^# to make the transition at their project-specific pace, so faster upstreams can pick up a newer version immediately and slower upstreams don't stall adoption of a new library for all other formulae. Eventually all formulae will have either transitioned to a newer version, so that legacy versions of a library can be removed, or they get boneyarded if they fail to make the transition to a newer version after a library-specific grace period.

^#) We'll try to keep the number of libraries where multiple versions are allowed to coexist small, and what libraries are eligible also depends on the library developers' commitment (or lack thereof) to API/ABI stability, something that can vary widely. Some discussion can be found in Homebrew/brew#60, but the details of the implementation are not fully worked out yet, thus that's not going to immediately help with the libgit2 situation.

[DomT4]

Closing in favour of #2324, but thank you for your submission to Homebrew @beniamino38; we appreciate it! ❤️