Thanks for working on this cruft cleanup Ævar and to
Jonathan & Junio for asking questions about how to improve
this transition for packagers & users.
Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
I don't think it's a big deal for the Fedora/Red Hat
packages to adjust and manually install the stub git-el.
Anyone doing automated rebuilds from the current Fedora
git.spec will notice the make failure and can then check the
relese notes to find out about the change, I imagine.
> 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.
I wonder if leaving the Makefile in place would prevent
packages from even noticing the change? It might still be a
good plan to help ease the transition. I don't know if
that's as important for something in contrib/ or not.
> 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.
I should note that I'm not an emacs user, so I likely lack a
good understanding of how people use the current
git{,-blame}.el files. I could simply be doing it wrong in
the steps I took to test this.
With the fedora packaging, we've shipped a git-init.el that
adds autoload entries for git-status and git-blame-mode
(since adding the emacs files in 2007). That allows users
to make use of those features without adding anything to
their local emacs configuration.
If I open emacs with a current fedora packaging, I can issue
M-x git-status or M-x git-blame-mode. After applying this
patch and removing the git-init.el, that no longer works
but rather than the detailed warning message, I just get a
transient "no matches" in the emacs status line.
However, if I add "(require 'git)" to ~/.emacs, then I get
the "error: git.el no longer ships with git" message in the
warnings buffer.
Does this mean that only users who have manually loaded
git.el will see the warning? If so, is there a preferred
method to have the warning appear when calling the commands
previously provided, to give a better user experience?
--
Todd
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Faith, n. Belief without evidence in what is told by one who speaks
without knowledge, of things without parallel.
-- Ambrose Bierce, "The Devil's Dictionary"
