emacs-devel
[Top][All Lists]
Advanced

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

Re: Bundling GNU ELPA packages


From: Nic Ferrier
Subject: Re: Bundling GNU ELPA packages
Date: Fri, 07 Nov 2014 08:44:24 +0000

address@hidden writes:

>>> The only downside I can see is that users upgrading from Emacs 24 to 25
>>> might get startup errors because formerly built-in packages aren't
>>> anymore.  But that can be documented easily:
>>> 
>>>   If you used the built-in org-mode version in Emacs < 25, do
>>> 
>>>     1. emacs -Q
>>>     2. M-x package-install RET org RET
>>>     3. Now you can restart emacs without -Q

I don't see why packages like this couldn't be delivered at
installation. The package could be bundled in the source repository at a
specific version and package-install-file'd into ELPA by the source
build.


I don't think the slimmed source build idea is a great idea because it's
already complicated. If we added that there would be 3 different package
styles.


It seems to me the package system is a bit confused, because people are
confused about packages. The confusion is greater in the wider Emacs
world.

One thing that causes that confusion is the ELPA repository. It's a
representation of packages, instead of packages.

I said before that I think ELPA should move to a package artifact store,
like marmalade-repo.

I think this because artifact stores are clearer. They just accept
package uploads and then give them out to users.

With ELPA there is a hidden build process. How many ELPA package authors
build their package and test it before committing? (this situation is
one of the reasons I don't like MELPA, the build is also hidden).

It's also not very scalable I think, eventually the git repo will get so
big it will be hard to move around. I'm sure we can spend time and energy
coming up with a solution to that but why?

GNU wants a package archive? make a package _archive_ not a source
repository. The source repositories for ELPA packages could be required
to exist on savannah, where projects belong, and they should be able to
have their own project management.

And they should deliver packages. Not some half thought out
representation of their package as a directory.

This might require package archive software, but I have one that is
GPLed (and even written in elisp) and it might require a build tool, but
I have one (written in elisp).

So I don't see why we shouldn't do packages _properly_


TL,DR - current ELPA combines release and build, hides build and merges
projects together. We should stop and go to the "standard" model.



reply via email to

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