Re: "Write a new package" culture instead of patches?

[Yoni Rabkin <yoni@rabkins.net>]

Clément Pit-Claudel <cpitclaudel@gmail.com> writes:

> On 18/05/2020 13.30, Yoni Rabkin wrote:
>> I agree that it is their right to distribute Emms as they wish as long
>> as they abide by the terms of the license, but I do not agree that their
>> particular form of distribution is good for Emms (no quality control for
>> those "needed by" projects; do they even work?) or if it is good for the
>> people who enjoy Emms (maybe they steer people to use proprietary
>> services.)
>
> There is a bit of quality control, at package submission time (things regarding proper API documentation, proper namespacing, etc. — but nothing like tests, indeed).
> I think the way they display thing isn't much different from what you
> get with "apt-cache rdepends" on a Debian system (it's not the same as
> the `Recommends: mpg321` or `Suggests: mp3info` lines that `apt` shows
> when I ask it `apt show emms`, for example).
>
>>>>     * Not even linking to the Emms home page
>>>>       (https://www.gnu.org/software/emms/).
>>>
>>> I think it does: I see this when I open the package in M-x list-packages:
>>>
>>>    Homepage: https://www.gnu.org/software/emms/
>>>
>>> The MELPA website links to the git repository instead.
>> 
>> Yes, that was what I was referring to.
>
> Good point; I opened a ticket about this.

thank you

>>>>     * Find a way of packaging a project as-is. For instance, Emms could
>>>>       be distributed as is, and the M/ELPA software could simply point
>>>>       at where Emms keeps its .el files for Emacs to find. This is
>>>>       instead of how I see ELPA working now, which is to force the
>>>>       software through a kind of a sieve (I think ELPA calls it a
>>>>       recipe) where only a select few files come out the other end.
>>>
>>> It's trivial to make a recipe that includes all files, so I wouldn't
>>> worry about this.
>> 
>> The Emms distribution already contains all of the files by defintion;
>> none needed to be remove to begin with. I feel like we looking at the
>> issue from two different viewpoints.
>
> The package manager that comes by default in Emacs 24+ is able to
> produce ELC and info files automatically, so packages typically don't
> ship Makefiles.  Additionally, it makes certain assumptions about
> archive layout that EMMS' releases currently don't abide by; that's
> why MELPA has recipes.
> Distributing through ELPA would require the same modifications: this is just the way package.el works. 
>
>>> It will be great to have an improved EMMS recipe in MELPA!  If you run
>>> into trouble, you should ask on the bug tracker; the MELPA folks are
>>> great.
>> 
>> Why does Emms need to be offered through three different channels at the
>> same time?
>> 
>> Ideally, I would contact the MELPA bug tracker and have Emms removed
>> from MELPA, since it can be trivially downloaded from a GNU server
>
> Downloading it from a GNU server is very complicated, compared to
> installing it through MELPA.

I personally disagree, but since people have asked me to make Emms
available via ELPA I'm disregarding my personal opinion on the matter.

>> and will hopefully soon be installable via ELPA.
>
> I hope you can put it in ELPA; that would be even better.

Yes, that is the goal.

>> However, since nobody asked last time they installed Emms there, nothing
>> would stop them from installing it on MELPA again, or modifying the
>> recipe to exclude files again. Since MELPA offers the Emms project no
>> control over distribution, I don't have much incentive to work on how
>> Emms is distributed there, or to fix it and then schedule a weekly
>> excursion to MELPA to see if someone has broken it.
>
> This is not how it will work: EMMS was one of the earlier packages to
> be included in there, before there was a policy to keep maintainers in
> the loop.  Today, it wouldn't be included without asking.
>
>> Please forgive me if I'm misunderstanding something fundamental about
>> how MELPA works. As I've mentioned before, I don't use it or ELPA.
>
> No worries. The short summary is that MELPA doesn't take an
> adversarial approach, so if you ask for your package to be removed, it
> will be removed.  But please don't, not before putting it on ELPA — it
> will break many users' configurations, since emms is rather popular
> there.

Once it is on ELPA, would that make the MELPA version redundant? Are
packages duplicated across ELPA and MELPA? If so, why?

> Do you keep statistics for your web server?  It would be useful to
> compare how many people install through MELPA and how many download
> releases directly.

Emms is hosted on Savannah, and I'm guessing that GNU/Linux distribution
grab copies of the release version from Savannah/GNU servers as well, so
even if we had those numbers, I wouldn't know how to make sense of them.

-- 
   "Cut your own wood and it will warm you twice"