From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: Supporting multiline Package-Requires header Date: Sun, 23 Aug 2015 08:33:11 +0200 Organization: Linux Private Site Message-ID: <87lhd2h5ug.fsf@Rainer.invalid> References: <87si7rjqmp.fsf@newcastle.ac.uk> <87fv3rjogj.fsf@newcastle.ac.uk> <87fv3po7ss.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1440311617 9911 80.91.229.3 (23 Aug 2015 06:33:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Aug 2015 06:33:37 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Aug 23 08:33:28 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 1ZTOqN-00062N-U0 for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2015 08:33:28 +0200 Original-Received: from localhost ([::1]:49411 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTOqM-0008CT-UM for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2015 02:33:26 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTOqJ-0008C3-7f for emacs-devel@gnu.org; Sun, 23 Aug 2015 02:33:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTOqG-00084a-1H for emacs-devel@gnu.org; Sun, 23 Aug 2015 02:33:23 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:38093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTOqF-00084E-Qh for emacs-devel@gnu.org; Sun, 23 Aug 2015 02:33:19 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1ZTOqD-0005xz-Da for emacs-devel@gnu.org; Sun, 23 Aug 2015 08:33:17 +0200 Original-Received: from p54b7e570.dip0.t-ipconnect.de ([84.183.229.112]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Aug 2015 08:33:17 +0200 Original-Received: from Stromeko by p54b7e570.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 23 Aug 2015 08:33:17 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 49 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: p54b7e570.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) Cancel-Lock: sha1:5ZwatJiSeCcfr4J4SH4qdYOpOnw= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:189077 Archived-At: Stefan Monnier writes: >> (or (lm-header "package-version") >> (lm-header "version") >> (unless (equal pkg "org") >> (error "Missing `version' header"))) >> >> Is this still necessary? I've finally had a look at what you're doing there. > Sadly, yes. But it should be "easy" to solve: ask the Org guys to put the > version of their package in org.el's pseudo-headers. The easy solution is to recognize that you already got a complete package archive from the Org guys which is ready to be deployed. > I put quotes around "easy" because they have a latent problem with their > version numbers. No, it's actually your expectation to have version numbers in the comments of a non-generated, version-controlled file that's a latent problem. Keeping that up-to-date would require a stream of otherwise useless commits in the VCS and result in merge conflicts while keeping the maint and master branch in sync. It may be sort of OK for simple packages, but for anything else it isn't. The only problem we have with the version numbers has been forced by an external package archive we have no control over and that never even put out a correctly packaged Org that would actually work when installed. But their versioning scheme has been org-YYYYMMDD. We'd totally switch to something like 8.3.1-56-g17a225-elpa if there was a way to make sure that the existing versioning scheme wouldn't get people stuck on outdated releases. Now, if you still insist on having these headers, the easiest way is to put them into org-version.el since that file is already generated. But you'd have to look there in preference of the "main" package file if it exists. I don't want to modify org.el just for ELPA and re-organizing the sources so that org.el becomes a generated file instead is possible, but not really something we'd normally do on the maint branch. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra