From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stephen Leake Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Sat, 14 Nov 2015 04:30:43 -0600 Message-ID: <86twooc1po.fsf@stephe-leake.org> References: <87ziyuaqhl.fsf@petton.fr> <868u65afvh.fsf@stephe-leake.org> <87lha5snji.fsf@isaac.fritz.box> <87d1vhsmuj.fsf@isaac.fritz.box> <878u65slue.fsf@isaac.fritz.box> <874mgtsjwn.fsf@isaac.fritz.box> <867flp8nb7.fsf@stephe-leake.org> <9e33129a-07d0-4abe-a94e-32d6d881519b@default> <86bnb06g7g.fsf@stephe-leake.org> <861tbwcju9.fsf@stephe-leake.org> <86pozfc7xb.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447513142 2724 80.91.229.3 (14 Nov 2015 14:59:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Nov 2015 14:59:02 +0000 (UTC) Cc: emacs-devel@gnu.org To: Filipp Gunbin Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 14 15:58:50 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZxcHy-0008PT-BF for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 15:58:50 +0100 Original-Received: from localhost ([::1]:35140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxcHx-0003VU-UF for ged-emacs-devel@m.gmane.org; Sat, 14 Nov 2015 09:58:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxY6o-0004QG-RF for emacs-devel@gnu.org; Sat, 14 Nov 2015 05:31:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxY6l-0002Ht-Lh for emacs-devel@gnu.org; Sat, 14 Nov 2015 05:31:02 -0500 Original-Received: from gproxy1-pub.mail.unifiedlayer.com ([69.89.25.95]:55183) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1ZxY6l-0002Hg-En for emacs-devel@gnu.org; Sat, 14 Nov 2015 05:30:59 -0500 Original-Received: (qmail 12916 invoked by uid 0); 14 Nov 2015 10:30:56 -0000 Original-Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy1.mail.unifiedlayer.com with SMTP; 14 Nov 2015 10:30:56 -0000 Original-Received: from host114.hostmonster.com ([74.220.207.114]) by cmgw3 with id hVWl1r00X2UdiVW01VWofm; Sat, 14 Nov 2015 10:30:54 -0700 X-Authority-Analysis: v=2.1 cv=Caqbutbl c=1 sm=1 tr=0 a=CQdxDb2CKd3SRg4I0/XZPQ==:117 a=CQdxDb2CKd3SRg4I0/XZPQ==:17 a=DsvgjBjRAAAA:8 a=f5113yIGAAAA:8 a=9i_RQKNPAAAA:8 a=hEr_IkYJT6EA:10 a=x_XPkuGwIRMA:10 a=qtqOOiqGOCEA:10 a=Zw6ykP5hX40qibA-yvAA:9 Original-Received: from [76.218.37.33] (port=61602 helo=TAKVER2) by host114.hostmonster.com with esmtpa (Exim 4.84) (envelope-from ) id 1ZxY6a-0007LD-0g; Sat, 14 Nov 2015 03:30:48 -0700 In-Reply-To: (Filipp Gunbin's message of "Fri, 13 Nov 2015 16:06:03 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (windows-nt) X-Identified-User: {2442:host114.hostmonster.com:stephele:stephe-leake.org} {sentby:smtp auth 76.218.37.33 authed with stephen_leake@stephe-leake.org} X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 69.89.25.95 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194451 Archived-At: Filipp Gunbin writes: > On 12/11/2015 13:52 -0600, Stephen Leake wrote: > >> I don't see why that is different from depending on a normal ELPA >> package. > > I think it's their dependants what make them different from tarball and > normal packages. > > Emacs core provides API, which others use. A normal package declares > which versions of this API it is supposed to work against. > > With core packages, Emacs still provides API, but it now consists of a > static part (C level & core) and dynamic part (core packages, which can > later be updated from ELPA - correct me if I'm wrong). So, a package > should independently define which core version it works agains and which > core package(s) version(s) it works against. package.el dependencies can only specify a minimum version, not a maximum. there is no way that a normal ELPA package can declare that it works with seq.el 1.0 but not seq.el 1.1 So if emacs 25 contains a core ELPA package seq.el 1.0, the declaration ;; Package-Requires: ((emacs "25.1")) is equivalent to: ;; Package-Requires: ((emacs "25.1") (seq "1.0)) If seq.el 1.1 is later released via the Gnu ELPA server, it will be used in either case. Listing a core ELPA package explicitly is only necessary when the emacs version is less than the first version that included the core ELPA package version. On the other hand, it doesn't hurt, so it's probably best to recommend listing all ELPA packages explicitly. >>> We'll probably have to calculate and offer to user which set of the >>> multiple core packages' multiple versions suits for multiple normal >>> and tarball (perhaps overriden by version from Internet package >>> archive) packages, at the same time probably giving the user to >>> opportunity to specify her preferred version of each requested >>> package. Is it worth the trouble? Or do I understand something wrong? >> >> Emacs does not support multiple versions of packages available >> simultaneously; there is only one instance of a package that is first in >> load-path. >> >> You can end up with one copy in the installed Emacs distribution, and >> one in ~/.emacs.d/elpa. But the elpa one will take precedence; that is >> the only one that other packages have to worry about. It either meets >> their dependency requirement, or not. > > Of course, I was talking about the set of available versions which could > be installed and from which a user or a package manager should choose. I still don't see a problem. We have an example of a core ELPA package now; ada-mode. version 4.3 is in emacs git; version 5.1.8 is in ELPA (if I ever get 5.x to be fast enough on huge files, I'll delete 4.3 from core). package.el has no issues with this. Similar things can occur when there are different versions of the same package in multiple repositories. In that sense, emacs git is just another package repository. Can you be more explicit about what problem you foresee? Give an example of a package that would cause a problem. -- -- Stephe