git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 12, 2018, 09:23 UTC
Message-ID
<xmqqa7u83hjd.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<87fu40c3xe.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
Show 17 quoted lines
>> 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.
Previous: Ævar Arnfjörð BjarmasonNext: Todd Zullinger
Message 6 of 7 in “git{,-blame}.el: remove old bitrotting Emacs code”
  1. git{,-blame}.el: remove old bitrotting Emacs codeÆvar Arnfjörð Bjarmason, Mar 10, 2018
  2. Jonathan NiederMar 27, 2018
  3. git{,-blame}.el: remove old bitrotting Emacs codeÆvar Arnfjörð Bjarmason, Apr 11, 2018
  4. Junio C HamanoApr 12, 2018
  5. Ævar Arnfjörð BjarmasonApr 12, 2018
  6. Junio C HamanoApr 12, 2018
  7. Todd ZullingerApr 18, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.