Re: [PATCH v4] git{,-blame}.el: remove old bitrotting Emacs code

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> On the other hand, the 6-lines of e-lisp you wrote for git.el
>> replacement is something the packagers could have written for their
>> users, so (1) if we really want to go extra mile without trusting
>> that distro packagers are less competent than us in helping their
>> users, we'd be better off to leave Makefile in, or (2) if we trust
>> packagers and leave possible end-user confusion as their problem
>> (not ours), then we can just remove as your previous round did.
>>
>> And from that point of view, I find this round slightly odd.
>
> I think the way it is makes sense. In Debian debian/git-el.install just
> does:
> ...
> RedHat does use contrib/emacs/Makefile:
> ...
> But they can either just do their own byte compilation as they surely do
> for other elisp packages,...

In short, Debian happens to be OK, but RedHat folks need to do work
and cannot use what we ship out of the box, *IF* they care about end
user experience.

That was exactly why I felt it was "odd" (iow, "uneven").  We bother
to give a stub git.el; we do not bother to make sure it would keep
being installed if the packagers do not bother to update their
procedure.

If we do not change anything other than making *.el into stubs, then
it is a lot more likely that end user experience on *any* distro
that have been shipping contrib/emacs/ stuff will by default
(i.e. if the packagers do not do anything to adjust) be what we
design here---upon loading they'd see (error) triggering that nudge
them towards modern and maintained alternatives.  If we do more than
that, e.g. remove Makefile, then some distros need to adjust, or
their build would be broken.

I suspect that the set of people Cc'ed on the thread are a lot more
familiar than I am with how distro packagers prefer us to deliber,
so I'll stop speculating at this point.

Thanks.