Pondering the Emacs add-on packaging situation

Jan Synacek jsynacek at redhat.com
Wed Jun 24 07:01:53 UTC 2015


Jonathan Underwood <jonathan.underwood at gmail.com> writes:

> Hi,
>
> So, while filing a bunch of bugs against packages not complying with
> the Emacs add-on packaging guidelines, I started to think about the
> state of add-ons for Emacs [1].
>
> Since those guidelines were put in place, Emacs has grown its own
> package manager (package.el, shipped with Emacs[2]), and now users can
> install something approaching 3000 packages from repositories like
> ELPA[3], MELPA[4] and Marmalade[5].
>
> The Emacs package manager installs these add-on modules in the user's
> own directory by default, but it can also install them in a system
> wide directory.

If you run Emacs as a regular user, you can install packages into system
directories? That would be news to me. Why would anyone do that?

> My thoughts are currently that:
> 1) Fedora doesn't have the manpower to package large numbers of
> packages from these repositories and keep the Fedora packages
> up-to-date
>
> 2) It may be possible to write automation tools like elpa2rpm,
> melpa2rpm, marmalade2rpm to automate packging for Fedora from those
> repositories, but such tools don't yet exist. Even if they did, the
> repositories usually aren't the canonical upstream for the packages.

Managing Emacs packages by the distribution makes, IMHO, no sense at
all. Users can easily manage the packages themselves via Emacs'
package.el user interface.

> 3) Even if we could generate rpm packages directly from the emacs
> package repos, package.el doesn't have any notion such as "installed
> but inactive" for packages, such that installing rpm packages of emacs
> packages would activate them for all system users, which is
> undesireable.

Again, I'm not aware of how a regular user can install Emacs packages
for all the users. If it can be done, you either have to have root
privileges, or there is some kind of Fedora-specific polkit rule or
something.

> So, I am not really sure what a good way forward is at this point.
> Certainly package.el could be extended to help us out in some ways,
> such as having a notion of "installed and available but not active".
> But is it worth the effort?

In my opinion, no. I will repeat myself: Emacs packages should be left
for users to install, since it's very easy to do, and they can choose
From stable/development versions.

> The whole issue is another case of competition between an application
> package managers (package.el) and system package management such as we
> have had to solve for perl, python, texlive etc etc. But it's not
> clear to me what a good solution would be for Emacs. I'd welcome any
> thoughts anyone has (especially Tom Tromey if he still reads this
> list).

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20150624/d4649290/attachment.sig>


More information about the devel mailing list