From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Core ELPA was: Testing fontification, indentation, and buffer manipulation Date: Thu, 07 Mar 2019 21:51:52 -0500 Message-ID: References: <7803c5de-e139-01ed-e9e3-98abb875782b@grinta.net> <2d777e7b-28d9-36a5-073d-b439fca9706a@grinta.net> <1548067539.3478998.1639830432.03003247@webmail.messagingengine.com> <87bm47558t.fsf@russet.org.uk> <87pnsm2vsm.fsf@russet.org.uk> <878sz7u2f5.fsf@russet.org.uk> <87o976p6xt.fsf_-_@russet.org.uk> <87tvgm7fnu.fsf@russet.org.uk> <87sgw6i89k.fsf@russet.org.uk> <875zt15y0x.fsf@russet.org.uk> <87sgw3bzod.fsf@russet.org.uk> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="107563"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: phillip.lord@russet.org.uk (Phillip Lord) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 03:52:44 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h25cq-000Rol-BZ for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 03:52:44 +0100 Original-Received: from localhost ([127.0.0.1]:36163 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h25cp-0001zK-Dp for ged-emacs-devel@m.gmane.org; Thu, 07 Mar 2019 21:52:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:59833) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h25c5-0001bN-RR for emacs-devel@gnu.org; Thu, 07 Mar 2019 21:52:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h25c4-0006qN-Nm for emacs-devel@gnu.org; Thu, 07 Mar 2019 21:51:57 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:33137) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h25c4-0006lZ-0W for emacs-devel@gnu.org; Thu, 07 Mar 2019 21:51:56 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x282prMC004272; Thu, 7 Mar 2019 21:51:53 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id E68F46A478; Thu, 7 Mar 2019 21:51:52 -0500 (EST) In-Reply-To: <87sgw3bzod.fsf@russet.org.uk> (Phillip Lord's message of "Sun, 03 Mar 2019 18:06:26 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6498=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6498> : inlines <7029> : streams <1815070> : uri <2808713> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:233903 Archived-At: > I'm unconvinced. I think a build should be repeatable. Imagine bisecting > a bug that has come up in an ELPA package when you are not sure whether > it's the package or Emacs core that has broken things. That's already a problem with Elisp packages (whether from GNU ELPA or elsewhere), so the fact that we bundle some of them doesn't make much of a difference in this respect. Dependencies between them *should* be limited so that GNU ELPA packages can be used with various Emacs versions (and vice-versa). >> I think on Emacs `master` we won't want to use fixed SHAs but will just >> use whatever's on `master` of elpa.git. On the release branch, we'll >> probably want to be more specific, using corresponding branches. > That might mean multiple branches of master which would produce a very > cluttered namespace. The problem is that ELPA currently uses a different > (non git) mechanism to identify the current version of every package; so > you can't identify this from git metadata (except for SHA!). I don't know what you mean. A branch/tag is just a name for an SHA, so I can't see why a branch/tag wouldn't work where an SHA does. In terms of namespace, we'd simply use an appropriate naming scheme, of course. >>> Finally, neither solve the problem -- if a branch or tag is add >>> EMACS/elpa/Makefile.in which exists in the ELPA repo, but not in the >>> clone on the local machine the build will fail. >> >> I think the use of branches/tags will make it sufficiently infrequent >> that it's not a big deal. Also the build shouldn't completely fail. > > Beyond removing the configure option, it will fail at the moment. I > could do something else beyond that. But surely, by default, the build > should fail, if something fails? I think currently I'd want bundled-GNU-ELPA packages to be treated as "GNU ELPA packages pre-installed for the user's convenience" rather than as "core packages that you can later upgrade via GNU ELPA". So it's OK if they can't build: Emacs should still be perfectly usable without its bundled-GNU-ELPA packages (which you can later install via GNU ELPA anyway). Maybe in the future, we'll want to allow some bundled-GNU-ELPA packages to be more important (e.g. be *necessary* for example because they're used by some core Elisp packages), but there's no need to cross that bridge now. Stefan