Dear zimoun, On Mon, Dec 05, 2016 at 11:52:26AM +0100, zimoun wrote: > Firstly, because some of these security issues are partially fixed by > Emacs 25.1, if I understand well. Then, I am sure they will be fixed > Emacs-side soon, I guess. Maybe not so soon for e.g., the package > signature or other fancy Debian-package features ; whatever. > > Therefore, from my point of view, the aim of a such tool corresponds > more to the use of all the Debian infrastructure (well-integration, > reproducibility, stability and "long-term" support, etc.). From what I > understand, it is the same sort of idea for Emacs-packages than for > Python-packages, R-packages, Perl-packages, etc. Each of them has its > own package manager working more or less efficiently, and they are > still packaged by Debian. And it is not necessary about security > reasons. All this package effort, is it not the same aim ? MELPA still pulls packages from a publicly editable wiki, which has nothing to do with Emacs 25.1! In general, you're right: the general Debian QA infrastructure is another big reason to use the elpa-* packages, even after the various problems with Emacs and MELPA get fixed. > Secondly, the need of administrator privileges to install `elpa-*` > packages is --from my point of view-- a drawback. But, it is a not > drawback of `elpa-*` package, it is a drawback about APT. Indeed. The primary use case for elpa-* packages is installation on a personal computer, such as a laptop. It would be great to see you in #debian-emacs. Also see <https://pkg-emacsen.alioth.debian.org> for introductory information. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature