emacs-devel
[Top][All Lists]
Advanced

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

Re: elpa.gnu.org repository sync with Emacs


From: Ted Zlatanov
Subject: Re: elpa.gnu.org repository sync with Emacs
Date: Tue, 16 Nov 2010 15:37:19 -0600
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

On Tue, 16 Nov 2010 21:21:40 +0100 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Tom Tromey <address@hidden> writes:
>> I also hope the distros move to using package.el for elisp activation.

LMI> The distros have perfectly good packaging solutions already, and they
LMI> have the QA in place to make sure that whatever you're downloading will
LMI> play nice with what you already have.

The problem is there are lots of distros and most don't have good QA in
place.  Debian and Ubuntu are hardly the norm.  The ELPA-style repos are
a way to work around the lack of standard packaging.

LMI> So we'd basically have the same situation that Perl has with CTAN
LMI> vs. the packages that (say) Debian has.  You can say "apt-get install
LMI> libemail-mime-createhtml-perl" and get a version of that library that
LMI> you know will work on your machine, or you can root around on CTAN,
LMI> download the latest version there, and it'll probably work -- except for
LMI> the times it doesn't, because it relies on something that's slightly too
LMI> new for your machine.

s/CTAN/CPAN/g :)

This problem is not solvable.  You have competing interests (distro
vs. users vs. developers) that are pulling in different directions.
ELPA-style repos for Emacs give control back to the developers and the
users in a distro-neutral way (much like CPAN, in fact).  In addition,
distros can take advantage of that facility and add their own ELPA-style
repos, but they probably won't.  They have a strong interest in keeping
the packaging in their own format, which is perfectly sensible to keep
QA and other costs down.

LMI> Decoupled packaging over the long haul is hard.  Making sure that
LMI> separate packages work together over a decade is difficult.
LMI> Dependencies change and stuff break.

That's the worst haiku *ever* :)

LMI> I want to be able to install Emacs in 2015 and just have it work without
LMI> getting into a morass of packages that I have to install from here and
LMI> there.  I want to say "apt-get install emacs", and possibly "apt-get
LMI> install slime" (if that's not in Emacs by then), and know that I have
LMI> something that has been tested to work on the machine I have then.

If you want QA from the distro you have to install their packages.

Ted




reply via email to

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