On Wed, 2021-03-17 at 12:21:24 -0700, Jonathan Nieder wrote: > Guillem Jover wrote: > > 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? > > Yeah, I don't advocate copying. Probably we should patch those > instructions at installation time to recommend sourcing in place > instead.
That'd be great yes. > The git-sh-setup(1) manpage recommends > > . "$(git --exec-path)/git-sh-setup" Ah! I've adapted my code to use that, thanks! > but there is no corresponding git-sh-prompt(1) manpage --- yikes. Having one, eventually, would be nice too. > 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 If the move stays, this seems desirable, yes. > 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. 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. > 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? While I like the libexec stuff in general, I think that indeed (b) > (a) > (c), given the current timing. Thanks, Guillem
