git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [Bug] git-credential-netrc.perl is not built and is not available in `exec-path`

From
Jeff King <peff@peff.net>
Date
May 23, 2021, 19:57 UTC
Message-ID
<YKqzj/DZU8m9AaI/@coredump.intra.peff.net>
In-Reply-To
<YKgzvFHOcUgPjbj/@camp.crustytoothpaste.net>
On Fri, May 21, 2021 at 10:27:08PM +0000, brian m. carlson wrote:
Show 10 quoted lines
> > I agree with this, but just following up with a bit of a devil's
> > advocate: why not put osxkeychain into a regular "make install", but
> > make it conditional via a Makefile knob, like we do for other
> > platform-specific features?
> 
> Sure, let's do it.
> 
> For osxkeychain, it's probably pretty simple to always build it, since
> macOS will always have the appropriate libraries if the compiler is
> installed.

Hmm. So I tried just building oxskeychain in our CI via contrib, and it fails. :(

It looks like it's OK with clang, but not gcc:
  https://github.com/peff/git/runs/2647748209?check_suite_focus=true

Maybe nobody cares about gcc for this use, but I'm inclined to leave it to somebody who actually runs macOS to poke at further.

> I would be in favor of also building by default on Linux and
> having a Makefile knob to disable that, since the requisite libraries are
> a part of nearly every distribution and doing so will spur distros to
> ship it, which many do not.

I assume you mean contrib/credential/libsecret here. I'd worry that flipping it on by default is annoying for people who build from source. I don't have dev libraries for things like libsecret or glib on my development system[1], and I'd be surprised if most server-oriented machines have even the non-dev versions.

Which isn't an argument against making it easier to build them from the main Makefile, but it seems like having them on by default (with a NO_LIBSECRET) would cause more surprises than the other way around (USE_LIBSECRET or similar).

I suspect that just opening a bug report against distro packages might get some traction (especially if it comes with a patch to create the extra package). I do wonder if packagers are hesitant to reach into contrib/, not knowing how well maintained the contents are (to be honest, I am not confident in how well maintained they are, either; it might be helpful if somebody who routinely used each helper stepped up to say that they would maintain it).

-Peff
[1] I was actually surprised I had libsecret installed at all.
    Apparently pinentry-gtk2 links against it, which I have for use with
    gpg. But my system might not be considered typical anyway, as I
    don't use any kind of "desktop environment".
Previous: brian m. carlsonNext: Felipe Contreras
Message 7 of 17 in “[Bug] git-credential-netrc.perl is not built and is not available in `exec-path`”
  1. SiavashMay 20, 2021
  2. Jonathan NiederMay 20, 2021
  3. SiavashMay 21, 2021
  4. brian m. carlsonMay 21, 2021
  5. Jeff KingMay 21, 2021
  6. brian m. carlsonMay 21, 2021
  7. Jeff KingMay 23, 2021
  8. Felipe ContrerasMay 24, 2021
  9. Renaming "non-contrib" things out of contrib/* (was "Re: [Bug] git-credential-netrc.perl[...]")Ævar Arnfjörð Bjarmason, May 24, 2021
  10. Felipe ContrerasMay 24, 2021
  11. Ævar Arnfjörð BjarmasonMay 24, 2021
  12. Felipe ContrerasMay 25, 2021
  13. Junio C HamanoMay 25, 2021
  14. Bagas SanjayaMay 25, 2021
  15. Felipe ContrerasMay 25, 2021
  16. Felipe ContrerasMay 25, 2021
  17. Jeff KingMay 21, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.