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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux