From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: GNU ELPA and package.el Date: Mon, 08 Apr 2019 19:55:22 +0200 Organization: Linux Private Site Message-ID: <87imvoz8j9.fsf@Rainer.invalid> References: <20180821162043.GA3946@ACM> <20180823213418.GA32596@ACM> <83lg8w9mt2.fsf@gnu.org> <871saoc70o.fsf@gmx.de> <87wosebzur.fsf_-_@gmx.de> <87tvnh9yg6.fsf@gmx.de> <8736myq6wo.fsf@gmx.de> <87y34o704v.fsf@Rainer.invalid> <87mul2p9m0.fsf@Rainer.invalid> <87sgut7m3o.fsf@Rainer.invalid> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="139773"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 08 19:56:22 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 1hDYVK-000aEF-1F for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 19:56:22 +0200 Original-Received: from localhost ([127.0.0.1]:56778 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDYVI-0005ta-US for ged-emacs-devel@m.gmane.org; Mon, 08 Apr 2019 13:56:20 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:51588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDYUh-0005tK-IB for emacs-devel@gnu.org; Mon, 08 Apr 2019 13:55:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hDYUg-00067x-Ad for emacs-devel@gnu.org; Mon, 08 Apr 2019 13:55:43 -0400 Original-Received: from [195.159.176.226] (port=33602 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hDYUg-00066z-1E for emacs-devel@gnu.org; Mon, 08 Apr 2019 13:55:42 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hDYUX-000ZIN-Um for emacs-devel@gnu.org; Mon, 08 Apr 2019 19:55:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:ucUKUKPK8g899vy7rwvSX63JFdg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:235125 Archived-At: Stefan Monnier writes: > elpa.gnu.org generates the packages from the various branches of elpa.git. > So I'm not sure where it should get its version info if not from version > controlled files. As I said, I'll happily make an exception for ELPA as long as it's hobbled to not allow a proper build and provide any number of extra pre-generated files that make up for the difference. What I do not want to do (Org maintainer override is possible) is to alter files from their state in orgmode.git (i.e. if you delete the pre-generated files the result should be identical to a checkout from orgmode.git). > What alternative do you suggest? Either use one of the generated files (via a suitable naming convention) as before, or take information from either/or tags and notes? > Hmm... IIRC since that discussion package.el was changed to try and > address those problems (starting with > c13baa10d55ec863d3ceaea48c6b2959ece98198, on Dec 2014). > > So if there are remaining issues, could you open a new bug report? I no longer have the test scaffolding in place that allowed me to check for this across a number of Emacs versions. IIRC, the changes back then addressed only that part of the problem that was immediate (i.e. the package would either fail to compile or activate). > Not sure in which way that's related to the issue of system-wide > ELPA packages. What I'm trying to say is that users might easily find themselves in the situation that requires them to ignore part of their system installation (which they can't do anything about because somebody else provides it). While it is an unlikely case, I think it should still be possible. > One way we could do this is to always prefer the user-installed version > over the system-wide one (tho, this will inevitably be somewhat brittle > since we actually don't truly know which directories are "user" and > which are "system", we can only approximate it e.g. by checking if we > have write access or by declaring that package-user-dir is the only > user directory and all others are system-wide). The order of all package directories provides a hierarchy already and in most cases the highest rung should provide the definite information. That part is mostly working already, I think. The missing part is masking single packages at any point in the hierarchy without requiring the user to have write access to those directories. >> More generally, being able to "delete" a package at any level (or making >> it completely invisible) is immensely useful for testing. > > I still don't know what you mean by "delete" here. s/delete/mask/ Does that make more sense now? I'd be happy if you find a better word for it. > I sense that you're venting a lot of frustration, but it's difficult to > move forward without clear and concrete cases to discuss. No I don't, life's too short for that. Anyway, as you say, lets move things along a bit. So, let's say the system has a package "Foo" installed and the user wants to install and use an older version of that. Another useful case is to pretend the builtin package "Bar" wasn't there, lets say for testing purposes (or top prevent problems on upgrading to a much newer version in the user or system space). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables