From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages Date: Thu, 20 Apr 2023 21:46:32 +0300 Message-ID: <83wn264cjb.fsf@gnu.org> References: <87a5zj2vfo.fsf@gmail.com> <834jpifizy.fsf@gnu.org> <83y1mue1qi.fsf@gnu.org> <83sfd2e01f.fsf@gnu.org> <1a5e5837-513b-84d8-3260-cdbf42b71267@gutov.dev> <83sfcz9rf2.fsf@gnu.org> <09a49ab9-ac72-36a9-3e68-9c633710eba7@gutov.dev> <83r0sh8i1q.fsf@gnu.org> <83a5z482e3.fsf@gnu.org> <83sfcu6g1l.fsf@gnu.org> <83a5z2646y.fsf@gnu.org> <453fdbd2-a29c-5ba6-0e16-21fd8f338f10@gutov.dev> <835y9q62er.fsf@gnu.org> <831qke5zar.fsf@gnu.org> <87pm7y31ni.fsf@posteo.net> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27871"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 20:47:16 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ppZJM-000704-QI for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 20:47:16 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppZIb-00053u-CL; Thu, 20 Apr 2023 14:46:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppZIR-00053Y-No for emacs-devel@gnu.org; Thu, 20 Apr 2023 14:46:20 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppZIR-00024o-7r; Thu, 20 Apr 2023 14:46:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=VnTGjwBQavrTM2lHDA1YGS7Bxvu42ft/LIn2HnU0l+Q=; b=Kbt1SoEKU1f1 TUD7KQl8dbJNWvutforOeV330ZXACmkVVwveg39GUTfYDD1wHS9pnvTPJe0nsKf9Sbb00zL+DDsjT KQxZp4dnnYlXoFxKFeFxiHDeX0mJURM4D17ML2H2t+WgFMf+Iai7SB8LdG6eZrU/vD8FX6FoX9j9n 1oMnWMdCCA3poTryuL5AC9G7SYA+dIpZp7JPvsWDMUBbHMnWTmIbQ9x5h4VU95J81Am3dpHYyH/uc cshoqaU6AMGEdU33QT0hevMACoAcJ98BALU2Ks/FrYoHTBBr/4872J98CKk1vJzyqVnQQcnu2jpGR 55+OeYEvFY4nqibaty8iPw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ppZIQ-0004jW-Iv; Thu, 20 Apr 2023 14:46:18 -0400 In-Reply-To: <87pm7y31ni.fsf@posteo.net> (message from Philip Kaludercic on Thu, 20 Apr 2023 17:26:57 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305523 Archived-At: > From: Philip Kaludercic > Cc: Dmitry Gutov , joaotavora@gmail.com, > emacs-devel@gnu.org > Date: Thu, 20 Apr 2023 17:26:57 +0000 > > Eli Zaretskii writes: > > > That core packages will be only in elpa.git, not in emacs.git. Then > > we'd "bundle" them with Emacs when preparing the release tarballs. > > > > I believe this is a long-term plan wrt core packages. It was even > > discussed a couple of times here. > > For people building Emacs from source, would this mean that they > would have to manually install core packages? No. We'd need to change either the build process or the structure of emacs.git (and consequently what happens when you say "git pull") so that manual installation will not be required. This was all discussed in the past, and this aspect was mentioned as one of the issues that would have to be solved. > Also, this sounds like it would make it impossible for package.el to > be distributed on ELPA, as proposed in another thread. It's possible, yes. But no one has yet got this far into designing such a system as to figure all that out. So other alternatives could be workable.