Ævar Arnfjörð Bjarmason <ava...@gmail.com> writes: > However, since downstream packagers such as Debian are packaging this > as git-el it's less disruptive to still carry these files as Elisp > code that'll error out with a message suggesting alternatives, rather > than drop the files entirely[2]. > > Then rather than receive a cryptic load error when they upgrade > existing users will get an error directing them to the README file, or > to just stop requiring these modes. I think it makes sense to link to > GitHub's hosting of contrib/emacs/README (which'll be updated by the > time users see this) so they don't have to hunt down the packaged > README on their local system. > ... > > contrib/emacs/.gitignore | 1 - > contrib/emacs/Makefile | 21 - > contrib/emacs/README | 32 +- > contrib/emacs/git-blame.el | 489 +---------- > contrib/emacs/git.el | 1710 +----------------------------------- > 5 files changed, 25 insertions(+), 2228 deletions(-) > delete mode 100644 contrib/emacs/.gitignore > delete mode 100644 contrib/emacs/Makefile
I know I am to blame for prodding you to reopen this topic, but I am wondering if removal of Makefile is sensible. Is the assumption that the distro packagers won't be using this Makefile at all and have their own (e.g. debian/rules for Debian) build procedure, hence *.el files are all they need to have? The reason why I am wondering is because I do not know what distro folks would do when they find that their build procedure does not work---I suspect the would punt, and end users of the distro would find that git-el package is no longer with them. These end users are whom this discussion is trying to help, but then to these packagers, the reason why their build procedure no longer works does not really matter, whether git.el is not shipped, or Makefile that their debian/rules-equivalent depends on is not there, for them to decide dropping the git-el package. 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.
