1:12 p.m.
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.
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.
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.
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?
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,
Jonathan.
[1] https://fedoraproject.org/wiki/Packaging:Emacs
[2] http://ergoemacs.org/emacs/emacs_package_system.html
[3] https://elpa.gnu.org/
[4] http://melpa.org/#/
[5] https://marmalade-repo.org/
2:06 p.m.
The case I just fixed is a bit different - it's not something that comes
from elpa, melpa, etc., but is an add-on that was just a contributed part
that ships with mercurial. Probably many cases of emacs-foo fedora packages
are like this.
2:28 p.m.
On 23 Jun 2015 20:06, "Neal Becker" <ndbecker2(a)gmail.com> wrote:
The case I just fixed is a bit different - it's not something that comes
from elpa, melpa, etc., but is an add-on that was just a contributed part
that ships with mercurial. Probably many cases of emacs-foo fedora
packages
are like this.
Oh, sure. I wasn't referring at all to that case (which is quite common,
and we'll handled already in the Fedora infrastructure).
2:01 a.m.
Jonathan Underwood <jonathan.underwood(a)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
6:31 a.m.
On 24 June 2015 at 08:01, Jan Synacek <jsynacek(a)redhat.com> wrote:
Jonathan Underwood <jonathan.underwood(a)gmail.com> writes:
> 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?
No, sorry, I guess I was unclear - installing into the system
directories would only be possible if you were running Emacs as root.
> 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.
Well, that's the way I'm leaning too. But then, I could make similar
arguments for python, perl etc.
> 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.
No, as I say above, you could only install system wide as root, and
then the packages would be available to all users on the system.
> 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.
OK, thanks for your thoughts, very helpful.
Jonathan
7:03 a.m.
Jonathan Underwood <jonathan.underwood(a)gmail.com> writes:
On 24 June 2015 at 08:01, Jan Synacek <jsynacek(a)redhat.com>
wrote:
> Jonathan Underwood <jonathan.underwood(a)gmail.com> writes:
>> 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.
You could, but there's a difference. The python/perl packages
(libraries) can easily turn out to be a mess, because they are part of a
development environment. It also makes much more sense (to me, at least)
to have them installed system-wide.
(Not sure if my explanation is clear enough.)
OK, thanks for your thoughts, very helpful.
I'm glad I could help.
Cheers,
--
Jan Synacek
Software Engineer, Red Hat
10:19 a.m.
On 06/24/2015 07:31 AM, Jonathan Underwood wrote:
On 24 June 2015 at 08:01, Jan Synacek <jsynacek(a)redhat.com>
wrote:
> 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.
Well, that's the way I'm leaning too. But then, I could make similar
arguments for python, perl etc.
Exactly, and not in a good way! It seems to me that we worked hard to
create a packaging system that keeps the system updated and secure...
and now retrench away from the idea. The revisionists seem to argue two
things:
- it's too hard to keep large subsystems consistent and free from ABI
clashes, so we need project-oriented contained setups
- it's OK to give up on the security advantages of unified
system-level updates because subsystems have limited scope.
As you say, this argument is made about Emacs, Python, Perl, Node.js,
and containters in general. I am very troubled by this trend: at worst
it leads to stagnant, vulnerable backwater subsystems ( "over 30% of
official images in Docker Hub contain high priority security
vulnerabilities",
http://www.infoq.com/news/2015/05/Docker-Image-Vulnerabilities ); at
best, it means that the end users have to orchestrate several
independent update processes. Simply not keeping stuff updated is not an
option---usually, all the imporant data is in the project, and even a
contained compromise that didn't subvert the core OS means game over
("All my data was stolen/erased through a browser exploit, but at least
the kernel was not compromised".. NOT).
This fragmentation leads to weird effects, such as the one I just
discovered with Node.js: the standard 'node' installation fails to use
the system-wide packages installed by 'npm' and Fedora RPMs, because
they use different paths; the node subpackage RPMs are basically
unusable as delivered. This is because node upstream believes in 'local
packages'.
We should not give up on the principle of installing all software
globally, within the RPM framework. I hope there's a way to accommodate
subsystem-specific packages, but it probably requires specific things
in each environment, rather than a universal solution that works for
every one of them.
Now, there are a couple of tradeoffs and issues to consider:
- big collections, or lots of little packages (l think TeXlive is
overdoing it with 5323 packages)
- can system/global packages be overriden by a local copy (especially
if upstream prefers local)
- in particular, are global packages immediately usable, or do they
have to be 'linked' locally first
- does Fedora just fix the issues for itself, or do we try to push it
upstream
I think we should discuss these issues and had a consistent policy to
draw on in similar discussions in the future.
3254
days inactive
3255
days old
6 comments
4 participants
participants (4)
-
Jan Synacek -
Jonathan Underwood -
Neal Becker -
Przemek Klosowski