From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Filipp Gunbin Newsgroups: gmane.emacs.devel Subject: Re: ELPA policy Date: Tue, 17 Nov 2015 16:01:57 +0300 Message-ID: References: <87ziyuaqhl.fsf@petton.fr> <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> <86twooc1po.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1447765355 27217 80.91.229.3 (17 Nov 2015 13:02:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Nov 2015 13:02:35 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 17 14:02:20 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 1Zyftr-0003lb-Dt for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 14:02:19 +0100 Original-Received: from localhost ([::1]:58323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyftl-00069E-Uu for ged-emacs-devel@m.gmane.org; Tue, 17 Nov 2015 08:02:13 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:39242) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyfth-00068j-QN for emacs-devel@gnu.org; Tue, 17 Nov 2015 08:02:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zyftb-0008F4-QC for emacs-devel@gnu.org; Tue, 17 Nov 2015 08:02:09 -0500 Original-Received: from out5-smtp.messagingengine.com ([66.111.4.29]:60056) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zyftb-0008Ej-H1 for emacs-devel@gnu.org; Tue, 17 Nov 2015 08:02:03 -0500 Original-Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C5E3320ABF for ; Tue, 17 Nov 2015 08:02:01 -0500 (EST) Original-Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 17 Nov 2015 08:02:01 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=3XiP7wCKvkekwSaI0jprBBXvFL0=; b=LUYfyY kwpUpoCjz5PuBHtOWyaF6w42FfoQHSONyEinnjakRVgycPBFle/6QgWQr2wTVojh lqYaAomZWml0OESn8ZzoLjJWktxLZX7K+oJY16xjbn1td/hOtcDfC+VOTk93Ejx+ gQdwQagwYI1R5IcR0d8KZ6zn0Lt5texOeFy+A= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=3XiP7wCKvkekwSa I0jprBBXvFL0=; b=k8kWYeZCIaCU+v0+yKrli0EYfzg7iICXGI8t4WkqD7+aAWk eNZ4BrSTJQRI1TgrZwye6ENF2V0UAZ2NDzajROPfhGUVvFRo193GHbJt85w6ZAeN EiNnEv1CpQb4Zn7+Bf717VQGE3LQhHeXdde7DZOyX7xTxToBoQKcJEw5EEd0= X-Sasl-enc: CLS4UULqstcJOYyHc0BlZsdjp08W1oSdLxv1L8am7jsJ 1447765321 Original-Received: from fgunbin.local (unknown [94.25.218.10]) by mail.messagingengine.com (Postfix) with ESMTPA id 00EA668012D; Tue, 17 Nov 2015 08:02:00 -0500 (EST) In-Reply-To: <86twooc1po.fsf@stephe-leake.org> (Stephen Leake's message of "Sat, 14 Nov 2015 04:30:43 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (darwin) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 66.111.4.29 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:194640 Archived-At: Stephen, On 14/11/2015 04:30 -0600, Stephen Leake wrote: > 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 My words were more of a theoretical speculation rather than discussion of the current state of package.el. Some parts of API may be deprecated and removed, so it may be the case that a current package is not updated instantly and need to use some previous version of core package. While having a "single snapshot" of Emacs + core packages does not cause such issues (even if package does not specify maximum version which author of course does not know in advance, the package just doesn=E2=80=99t work and so the user can downgrad= e to previous "snapshot", that is, previous Emacs version), separate core packages update after installation of such a "snapshot" might move forward and thus break some normal package (and downgrade will not help - the user will not know what to downgrade - what package? or core emacs? And how can I downgrade a single (core) package?). Just theory, again. Ignore if it is irrelevant and I=E2=80=99m complicating things too = much. > 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. Will the user have the option to continue to use the tarball version instead of newer ELPA version? Or choosing which ELPA version to use? This may be needed when she uses previous major Emacs release, and current ELPA package version requires newer core APIs. >>>> 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. For now, I don=E2=80=99t know of any practical examples. But thanks for yo= ur time on this. Filipp