Ævar Arnfjörð Bjarmason <ava...@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.
