From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: Stability of core packages (was: Not easy at all to upgrade :core packages like Eglot) Date: Wed, 19 Apr 2023 18:51:17 -0400 Message-ID: References: <87a5zj2vfo.fsf@gmail.com> <871qkom3fj.fsf@posteo.net> <83mt3b4yfc.fsf@gnu.org> <87edonlsxi.fsf@posteo.net> <83jzyf4vzb.fsf@gnu.org> <871qknllkj.fsf@posteo.net> <83fs934pjf.fsf@gnu.org> <87wn2fk47y.fsf@posteo.net> <83sfd2g2ek.fsf@gnu.org> <875y9yfxrr.fsf@gmail.com> <87y1muefks.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> <83lein7m7g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15319"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Jim Porter , dmitry@gutov.dev, joaotavora@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 20 00:51:42 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 1ppGeL-0003mj-Dd for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Apr 2023 00:51:41 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ppGdY-0002T5-IS; Wed, 19 Apr 2023 18:50:52 -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 1ppGdX-0002Sw-KA for emacs-devel@gnu.org; Wed, 19 Apr 2023 18:50:51 -0400 Original-Received: from mail-pj1-x102c.google.com ([2607:f8b0:4864:20::102c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ppGdV-0008Id-RJ; Wed, 19 Apr 2023 18:50:51 -0400 Original-Received: by mail-pj1-x102c.google.com with SMTP id 98e67ed59e1d1-246fdb97191so213146a91.0; Wed, 19 Apr 2023 15:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681944647; x=1684536647; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=F95taxNeSsm6Vgf35QQ+wep7LEWwAS4PQ0f8nUx4Wjo=; b=GWgZx53/VbYIIX6S0b4bRgXtolApUChcAupJxCUz+GnCiVN+vANGdmgX099014RdeO kfBxtbovqooFEiIDu750js9foyTux03Q/Uorl5iZHT+PVNe5MEkfFCaJYOWA2Ti1exmn VdK94MWwwdjIYOsg870wXI3udgu7qjuBDGqjbZMozMw0elpmjqmYLgb1RIU9zLpkVTzV wO1BEJYhpi4qnooUBI9CmEeD3B02p5mRY0AENTBUxcP+CotDDp1vCOcG7UC7YLPSkDSK yFOBefAiHpkvjIm3+e22RrOaczUZXleppc3uGf7YAbQYabEO3s7xkzKwH3SnDGb7tNbK LuZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681944647; x=1684536647; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=F95taxNeSsm6Vgf35QQ+wep7LEWwAS4PQ0f8nUx4Wjo=; b=HSVVDSKusjIw7FFCZouDiMkMo4mvPM1YtbgioYEe53JpS0+NAUDxaKJlcrccHBnsYI wD4raYpVHglRZJhCHNGr5GE1ybbPbu3o/AAWZ9a+/Qh6r89UVD3ZRmFQOCnOCkentj7v IReKs4picpz+vN+fBduvNIFa8Ydm+TLtvDhqC/2evb2hDF1886Tv9yuEvxrDNDH6hjxD nTrDEeLfclupY8OSZc/bDixlxUX8yqvcPYz1LpOOcAR/FTweWcrT9lax5Vm13J7N6uij 5/36WIcmKh0AWAfoivfKYlxV8rYzvcDW4eSkYgLIZKFkdmXB5WcmGrTGEqltnSLKBdnN YqcQ== X-Gm-Message-State: AAQBX9e1EpXUoA6HC1UO9iKWYos3t3gfn+xMzylOOlA4X1ybd3NQGsqM Gr9mXRUj36QbyCq/r8lKCMvUYpen2Zr9FE47J6hn4vdt X-Google-Smtp-Source: AKy350a4ADMU/kCk693CurAvJyS9A8IW4JMKxcf3fp8KZb6GUksQtUDsP1o2yjNnSxfnEdSX/5I8dy4GORihGZLjGFE= X-Received: by 2002:a17:90a:670c:b0:246:8193:1fdc with SMTP id n12-20020a17090a670c00b0024681931fdcmr3990943pjj.3.1681944647036; Wed, 19 Apr 2023 15:50:47 -0700 (PDT) In-Reply-To: <83lein7m7g.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::102c; envelope-from=owinebar@gmail.com; helo=mail-pj1-x102c.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action 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:305475 Archived-At: On Wed, Apr 19, 2023 at 2:37=E2=80=AFPM Eli Zaretskii wrote: > > Date: Wed, 19 Apr 2023 11:22:10 -0700 > > Cc: joaotavora@gmail.com, emacs-devel@gnu.org > > From: Jim Porter > > > > On 4/19/2023 5:47 AM, Eli Zaretskii wrote: > > > Also, does package.el support "downgrading" to the bundled version? > > > Did anyone actually try that? In particular, what happens with the > > > dependencies the user upgraded together with the package being > > > "uninstalled", due to the minimum requirements of that package? > > > > I've done this in the past and everything works pretty much as expected > > from my recollection: you can uninstall a package that you got from > > ELPA, so afterwards, you'd just get the bundled version (you might need > > to restart; I always do). > > > > In addition, any automatically-installed dependent packages are marked > > with the status "dependency". You can remove no-longer-needed deps via > > 'package-autoremove'. When uninstalling a package interactively in the > > *Packages* buffer, it will even suggest that you remove unneeded deps > > when appropriate (see 'package-menu-execute'). > > IMO, downgrading to the bundled version should be much simpler and by > default should remove all the dependencies without asking and without > any need for manual user actions. > > In any case, I don't think this use case was considered or tried > enough for us to consider it a solved issue. I'm quite sure there's > more here than meets the eye, simply because this is rarely if ever > done. One of the design points of the unboxing package-management-wrapper I'm writing is maintaining distinct package areas with a notion of scoping. My purpose was to enable separate management of site-packages and user packages. A site administrator might have one set of packages, and a user might want different versions of those packages. So, the dependency calculation for user packages should allow for dependencies to be satisfied by site packages, but not vice versa (that's the scoping). The "delta" of the package set installed in the user area has to be enough to make the set of libraries "seen" by the user coherent. That is, say package A and B both depend on package C and all are in the site-level packaging area. Then the user wants a different version of package A, which requires a different version of package C. Coherence means that if the version of package B installed at the site level is incompatible with the desired version of package C, then a compatible version of package B will also have to be installed in the user packaging area. That set has to be transitively closed. But the separation into those two is just a default configuration. Arbitrary package areas can be defined, each with their own set of "in-scope" areas. One easily reversible way to add a new version of eglot would be to set up a new package area for it, with whatever other package areas are loaded being put in its scope, then install the minimum coherent set of packages into the new area. Then rolling back the update would be trivial, and it could be "committed" to the usual package area once the user was satisfied. My only other thought on this discussion, as a package (ab)user running multiple versions of emacs, is that package releases should be dependent on the emacs version installing it. What I see as available packages/upgrades when I list packages while running emacs 28 should probably be different (for some packages) than what I see while running emacs 25 or emacs 29. It seems like the release philosophy after version 24 has been conservative about changes to the run-time semantics per major release, so the versioning probably doesn't need to be conditioned on the minor version of the Emacs binary. Lynn