guix-devel
[Top][All Lists]
Advanced

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

Re: [PATCH 0/2] Add emacs-emms-player-mpv.


From: Ricardo Wurmus
Subject: Re: [PATCH 0/2] Add emacs-emms-player-mpv.
Date: Wed, 29 Jun 2016 22:07:07 +0200
User-agent: mu4e 0.9.16; emacs 24.5.1

Ludovic Courtès <address@hidden> writes:

> Alex Kost <address@hidden> skribis:
>
>> Ricardo Wurmus (2016-06-29 08:45 +0300) wrote:
>>
>>> Hi Guix,
>>>
>>> I think we need to rename the “emms” package to “emacs-emms”.  (This is what
>>> the first patch does.)  Currently, the emacs-build-system will only add to 
>>> the
>>> Emacs “load-path” the “site-lisp” directories of packages that start with
>>> “emacs-”.  I think it may be necessary to relax this requirement for cases 
>>> in
>>> which a non-Emacs package provides an Emacs mode.
>>
>> I agree!  I also think this check for "emacs-" is not needed.
>>
>>> In the case of “emms”,
>>> however, I think renaming it is justified.
>>
>> I agree, but note that there was a discussion about renaming all emacs
>> packages (geiser, magit, etc.) and making alisases for the old names:
>> <http://lists.gnu.org/archive/html/guix-devel/2015-08/msg00316.html>
>
> A year later, it still looks like a good idea.  :-)
>
> Damn it, we should do something about it.

I’ll add it to my list in the hope that I can mark it DONE without
having to implement it myself :)  This is how things often go as far as
Guix is concerned.

>>> The second patch adds an EMMS player.  The byte-compilation phase only
>>> succeeds after renaming “emms”, because otherwise it wouldn’t find the lisp
>>> files provides by that package.
>>>
>>> Ricardo Wurmus (2):
>>>   gnu: emms: Rename package to "emacs-emms".
>>>   gnu: Add emacs-emms-player-mpv.
>>
>> Both patches look good to me, but I would wait for other comments about
>> renaming as it is not very backward compatible :-)
>
> A mass rename would cause users a lot of pain, but a single package is
> OK, IMO.

Do you want me to define an alias for “emms” now in the manner you
suggested in your email from 2015?  Or should this be done once the UI
supports dealing with deprecated packages?

~~ Ricardo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]