From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: feature/package+vc 04c4c578c7 3/4: Allow for packages to be installed directly from VCS Date: Sat, 22 Oct 2022 15:59:31 -0400 Message-ID: References: <164484721900.31751.1453162457552427931@vcs2.savannah.gnu.org> <20220214140020.04438C00891@vcs2.savannah.gnu.org> <87bkqmqpvb.fsf@posteo.net> <87edv96q4j.fsf@posteo.net> <83tu455a5s.fsf@gnu.org> <87a65v2ytp.fsf@posteo.net> <834jw33rmx.fsf@gnu.org> <87pmer0xtz.fsf@posteo.net> <83wn8z2aze.fsf@gnu.org> <878rle1i0k.fsf@posteo.net> <87ilkelc10.fsf@posteo.net> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12245"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Philip Kaludercic Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Oct 24 02:19:20 2022 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 1omlBX-0002xH-KP for ged-emacs-devel@m.gmane-mx.org; Mon, 24 Oct 2022 02:19:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1omjMQ-000134-TW for ged-emacs-devel@m.gmane-mx.org; Sun, 23 Oct 2022 18:22:26 -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 1omKeZ-0002kP-Lj for emacs-devel@gnu.org; Sat, 22 Oct 2022 15:59:31 -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 1omKeZ-0003hh-DO; Sat, 22 Oct 2022 15:59:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=mz/usUtGpiqX+Rixz1Osp6Bf6yQsWKfU3KMHWX+705c=; b=aObiWmjb6k4P hma2ASZlRvIfGoveimQzGm3iIGs6KAwWeHGVwM8y1iwqJnaKZ0FmH07Yh2PykhmgM41SQxF6aMP/o pOmQXQ/Lj8Lyhoj4NDAVLtnkG+mWY3KHiNo5gl4V+wewhSNXLTHHqdc8IsiKuokad6tiNTg26qket u/9LqMJRHjuIqs2opIVpP9kvUnvcJEnvI6mEi3CoqO3rveCWK7Qs/a8hN4aXYf8L4k2JYpXrn5gP5 CZ+PZUUYpNvBKmCCAogXe8CQ9VRCZsdVLsMbyYq89r6ZQnjp9qJ7ywnAqy4R5ydZCfD8tkUeqMceq 8UWRxcQHI5YjanthfI5Axg==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1omKeZ-0000rf-4t; Sat, 22 Oct 2022 15:59:31 -0400 In-Reply-To: <87ilkelc10.fsf@posteo.net> (message from Philip Kaludercic on Thu, 20 Oct 2022 16:01:31 +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" Xref: news.gmane.io gmane.emacs.devel:298279 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > If the main purpose of this feature is for people to test, debug and > > develop the development version, I think it is wiser not to speak > > of "installing" from VCS. > Not necessarily, another advantage might include the ability to maintain > personal changes that don't get overridden by updates. That would be a useful feature. But I think it would be unfortunate (and not what users want) to tell them, "To make and save your own patches, switch to the development version of the package." It would be better to offer a way that you can install your own patches _in the released version_, which is probably the version you were using and wrote the patches for, and then preserve these patches when you install new released versions. > In general I would like to see something like "package-vc" being > regarded as a means to make software freedom more practical/perceptible. That is a good general goal, but I don't think it applies to this question. Whether you want to try a development version is one question; whether you want to make patches (and desire to preserve them across updates) is another question. Let's make the latter feature available for the reeased package also. I understand that may be some extra work. However, merging your local patches with upgrades is not always going to be trivial and trouble-free. Often there will be no conflict, but sometimes there will be one. One way or another, you will need to be prepared for that if you start preserving your patches across upgrades > > Presenting the feature as a way to "install" would encourage people > > who are not really thinking of testing, debugging or developping the > > package, and motivated only by a vague wish for "the latest thing." > I agree that people might think of this idea, but then again what is the > issue if they do? They are likely to get different behavior, and more bugs. There is a good reason for making releases: in general, that makes things more reliable for users. That applies to packages as well as to Emacs overall. Running the development sources of anything carries greater risks. Some users want to take those risks, but it would be a mistake to urge all users to do that. > I proposed a library along those lines last year that would automate > this (it was called "site-lisp.el" in case you want to look the > discussion up). It automatically byte-compiles, prepares autoloads and > adds the directory to the load path for all files/directories in > ~/.config/emacs/site-lisp. This leads me to ask two questions: Would my proposed package-vc-dev command, plus this, add up to the currently proposed package-vc-install command? Would this be just what the user wants for preserving patches in packages installed from the release? By the way, GNU ELPA and NonGNU ELPA both have a repo which holds the current released version of each package. Imagine a package-vc-release command that does a checkout of the released package from ELPA, in the same way. That would help people add patches to the released version, and would merge changes when a new version is released. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)