Hi!

The latest version in sid, breaks user code sourcing the git-sh-prompt
shell library as it moved from /usr/lib/ to /usr/libexec, even though
I see the comment there says to copy it, but that means no automatic
upgrades. :/

Could you perhaps add a backwards compatibility symlink for the time
being? Or when using bash, perhaps even a warning based on the
“caller” builtin if using the old pathname?

Thanks,
Guillem

Control: severity -1 serious
Control: retitle -1 git: Moved libexecdir breaks add-ons

It also breaks various add-on packages installing files into
/usr/lib/git-core, as seen in the gitbrute autopkgtest[1]:

,----
| git: 'brute' is not a git command. See 'git --help'.
`----

The following packages install one or more files below /usr/lib/git-core
and are likely broken now:

,----
| $ apt-file search /usr/lib/git-core | cut -d : -f1 | sort -u
| brz
| git-absorb
| git-crecord
| git-flow
| git-quick-stats
| git-restore-mtime
| gitbrute
| imediff
`----

Adding a compatibility symlink seems to be a non-starter with packages
installing files there.  I think for now the change needs to be
reverted, and a transition plan worked out if moving git's libexecdir is
still desired.

Cheers,
       Sven


1. https://ci.debian.net/data/autopkgtest/testing/amd64/g/gitbrute/11098519/log.gz

Hi!

Guillem Jover wrote:

Yeah, I don't advocate copying.  Probably we should patch those
instructions at installation time to recommend sourcing in place
instead.

The git-sh-setup(1) manpage recommends

	. "$(git --exec-path)/git-sh-setup"

but there is no corresponding git-sh-prompt(1) manpage --- yikes.
Ideas:

 a. We could add a NEWS.Debian entry to help people see that the path
    changed and recommend using the $(git --exec-path) based incantation

 b. We could move $(git --exec-path) back to /usr/lib/git-core.  After
    all, while the FHS _allows_ libexec nowadays, it does not require
    it.

 c. As you suggest, we could have a compatibility forwarding script
    that warns to help people update their prompt configuration.

I think I prefer (a) over (c), and that (b) might be best of all.
What do you think?

Thanks,
Jonathan

clone 985351 -1
retitle -1 changing gitexecdir breaks packages that install commands there
severity -1 serious
quit

Hi,

Sven Joachim wrote:

This seems like a different issue from the one Guillem reported,
though it has the same proximate cause.

I suspect these should install to /usr/bin/ instead.  The exact
location where git stores its commands is an implementation detail
that packages are not meant to rely on.

Thanks,
Jonathan

Just to clarify, I meant compatibility symlinks for the script, not
for the directory, either that or a wrapper could do too. But if this
is affecting other stuff then reverting might be more prudent now.

Thanks,
Guillem

That'd be great yes.

Ah! I've adapted my code to use that, thanks!

Having one, eventually, would be nice too.

If the move stays, this seems desirable, yes.

As Sven has mentioned, given that this breaks other packages, even if
they are doing it wrong, breaking them at this point in the release
might not be ideal.

While I like the libexec stuff in general, I think that indeed
(b) > (a) > (c), given the current timing.

Thanks,
Guillem

And do a transition with Breaks against the non-migrated versions of
packages that rely on the current path.

Sounds doable for bookworm, but would also make git in
bullseye-backports harder to use for users of broken
packages or require backports also of these packages.

If this was only done to please lintian, I would vote for that option.

cu
Adrian