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: Sun, 07 Apr 2019 09:17:43 +0200 Organization: Linux Private Site Message-ID: <87mul2p9m0.fsf@Rainer.invalid> References: <20180819204918.GA3934@ACM> <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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="246569"; 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 Sun Apr 07 09:18:38 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 1hD24b-00120w-8l for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 09:18:37 +0200 Original-Received: from localhost ([127.0.0.1]:35467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hD24a-0000P4-9c for ged-emacs-devel@m.gmane.org; Sun, 07 Apr 2019 03:18:36 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:54287) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hD23x-0000Ow-Vk for emacs-devel@gnu.org; Sun, 07 Apr 2019 03:17:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hD23v-0000Wz-Qn for emacs-devel@gnu.org; Sun, 07 Apr 2019 03:17:57 -0400 Original-Received: from [195.159.176.226] (port=52744 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hD23s-0000UQ-0b for emacs-devel@gnu.org; Sun, 07 Apr 2019 03:17:53 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1hD23q-0011CI-3y for emacs-devel@gnu.org; Sun, 07 Apr 2019 09:17:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:b6Oy4LppttBxJu91yEjw5R5BWTc= 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:235061 Archived-At: Stefan Monnier writes: > I'm fully aware of that. But you can push the prebuilt packages to > elpa.it rather than pushing them to some third-party distribution site, > and let elpa.gnu.org build the corresponding tarball. This is the only > thing needed to eliminate the "Org hack". So the only thing you care about is that you don't want to deal with the tar file? The reason Org gives you the tar file is that we already had it available already (Org was distributing its own ELPA packages for quite some time already), plus we'd rather have ELPA serve the exact same tarball as you can get from Org's own site. Let me discuss this on the orgmode list and I'm sure we can find a solution. > This said, I'd love to get some help improving the elpa.gnu.org build > scripts so we can lift those restrictions altogether. > [ Basically, I'd like to be able to run those package-provided extra > build rules in some kind of sandbox, e.g. an LXC container; but given > the limited resources of elpa.gnu.org and its maintenance, it should > ideally re-use the Debian install already provided by elpa.gnu.org. ] Building the release tarballs on the Orgmode server (which used to be a very small VM on a shared box) didn't take all that much resources, but a fair bit of time depending on how much the machine was loaded from other tenants. Nobody's waiting on the build to finish so she can use it, so that works OK. I seem to remember some discussion about Gitlab for GNU. A Gitlab instance would usually provide CI pipelines that could produce release tarballs easily. If that's on the horizon I'd rather not muck about with building on the server (you are running code provided from external sources after all) or inventing your own CI just so you can do it a little more safely (however safe you think your hand-built solution is). >> The other unsolved problem is that anything that gets built in to Emacs >> releases still can't be later cleanly updated as a package because none >> of the "built-in packages" are actually packages in the ELPA sense. > > I don't know what problem you're thinking of. > You can definitely upgrade Org, python.el, and several others. > I can imagine scenarios where it can partly break, but most of them seem > contrived to me, so if you know of practical problems, please let > me know. The problem auf autoloads not being able to get redefined in a running instance of Emacs. I posted example code, a horrible hack of cleaning the data structures manually and we've discussed if it was possible to start a "clean" Emacs for byte compilation to work around this. The problem was exacerbated by the fact that some Org autoloads would end up in the global loaddefs.el, a problem that has since been fixed IIRC (but can creep in any time again). >> Last but not least I'll mention again that even if the two points above >> were solved, there still is not mechanism to cleanly separate packages >> installed at the system level (either with the Emacs release or >> separately by the admin) and user-level packages. Specifically, if >> packages are installed at the system level, the user can either use them >> all or none of them, but can't really chose on a per-package basis >> (without jumping through a number of burning hoops, that is). > > Currently, this choice is made via package-load-list. That was the > initial way to do that, and there hasn't been much noise about it since, > so it hasn't seen much activity, but we could make it more flexible > if needed. How do you imagine the user making this choice? > You mean you'd like to have a "clickable UI" or something else? Well yes, most users that can't install their own packages, but can use package.el would be at loss to do it via package-load-list, but are not expected to have problems if package.el told them which versions of a package are avilable on their system and where and which of thos they want to use (or install one from a package archive). The other thing package.el doesn't do at the moment is to "delete" a package that is either built-in or installed system-wide without replacing it with a user-installed (later) version. >>> What you can do is create a Tramp package on elpa.git and push releases >>> there (complete with the pre-built auxiliary files). >> Well, that'd be more or less the same hack as you use for Org, except >> you use Git instead of an archive file. > > That's a big difference for the build scripts. See the beginning of this post. >>> This is what AUCTeX does, basically (where the files that would >>> ideally be auto-generated during packaging are instead stored in the >>> elpa.git repository after making them manually). >> That is a mistake and should not be forced on anyone. > > I don't consider it a feature, but other than complaints, I haven't > gotten much help in trying to improve the situation. The last time I tried to discuss the requirements of moving this along (this really ties into so many places in Emacs that hopefully we have clear specifications of what to implement before actually starting it) it was either falling on deaf ears or producing almost allergic reactions. Not blaming anyone for not wanting to add to their to-do list, but I didn't see a way forward and dropped it. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves