From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#69528: 30.0.50; [BUG] transient.el is not a member of package--builtin-versions Date: Sun, 2 Jun 2024 10:36:26 +0000 Message-ID: References: <87edcrtegz.fsf@gmail.com> <87sf15rjyf.fsf@gmail.com> <8734t5yh49.fsf@posteo.net> <87edcp9p54.fsf@breatheoutbreathe.in> <878qzypbav.fsf@posteo.net> <86ed9qyxnm.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="32103"; mail-complaints-to="usenet@ciao.gmane.io" Cc: iarchivedmywholelife@gmail.com, 69528@debbugs.gnu.org, joseph@breatheoutbreathe.in To: Eli Zaretskii , Philip Kaludercic , Stefan Monnier , Andrea Corallo Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jun 02 12:38:11 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1sDibK-00085q-U5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 02 Jun 2024 12:38:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sDib1-00061F-FV; Sun, 02 Jun 2024 06:37:51 -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 1sDiaz-00060c-U0 for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2024 06:37:49 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sDiaz-00078k-Lh for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2024 06:37:49 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1sDibB-0002Vg-Po for bug-gnu-emacs@gnu.org; Sun, 02 Jun 2024 06:38:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Jun 2024 10:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69528 X-GNU-PR-Package: emacs Original-Received: via spool by 69528-submit@debbugs.gnu.org id=B69528.17173246679628 (code B ref 69528); Sun, 02 Jun 2024 10:38:01 +0000 Original-Received: (at 69528) by debbugs.gnu.org; 2 Jun 2024 10:37:47 +0000 Original-Received: from localhost ([127.0.0.1]:57920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sDiax-0002VE-4p for submit@debbugs.gnu.org; Sun, 02 Jun 2024 06:37:47 -0400 Original-Received: from mail-lf1-f42.google.com ([209.85.167.42]:61556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sDiav-0002V0-7B for 69528@debbugs.gnu.org; Sun, 02 Jun 2024 06:37:45 -0400 Original-Received: by mail-lf1-f42.google.com with SMTP id 2adb3069b0e04-52b82d57963so3239855e87.2 for <69528@debbugs.gnu.org>; Sun, 02 Jun 2024 03:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1717324587; x=1717929387; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=/vdldenti0Y/mcocqpnnfSX2U24NWULQ/OSBYuWGsZ8=; b=lUZG8TGRXj9iSh4dIT/mH6yXHcVkpAE3035FYx/CYAUiUgDMvGcRTUQy2U641FZRax neKQUGfa0dP15FoosJyZU5/rfuyengzyN+4syBqoZyWbiLfsikKeAqt0D4wJHWqCG0t2 23vhmDRNvNlCQgAQoWM9qIzlYesNUDxSVfshKGX0LXgKeILrBdXjqa+Mp5dvJ3ZaKHnb 83TLdcgkZT4ynJj9jC9/dYJsyhzTaavwx/5nLO/RwE20M5q1ewPQrkqPzFV+UW2vhj4w 3C/hmisd1Z3A/nweI/urUY0a2jHYjJIE5ihiQFbZwzyyWbIotX8Q+iEglCbMcGdAJZqB rbyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1717324587; x=1717929387; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=/vdldenti0Y/mcocqpnnfSX2U24NWULQ/OSBYuWGsZ8=; b=ixHXOUa+5bbuO0ppMo/Z42JZnop3xQfJxTSkcK8S5G3pxTvG/LzHymsp0BPbpxZgTO 2c3s3h4St3B2OfTRz5V3OxcdjgagcKXSW+VKflArR9GqzA8864o3no30OQ78eHZh2K7P HYXQmsiWF1vDy2wlnGAbnS4dOGTUhwy80NkqXsICDhHVVmEWYqTPQcoJkB1R2KknTPPY Igo2HOcEjs64EhMbMEaY2m9EjjL7T71WkL75a6cjzY6m10Ib4w+vnQmnb73H0ma6YsnS Vqnf6dQ5m3CqAeFlFucaJ9pZLirg+U5gOMYJwFu3sCmaUuUADGhxgj0gXgABLI+byfKD dBPg== X-Forwarded-Encrypted: i=1; AJvYcCU49IP4SeKtUbeGoAvl/zT2aiGMj4G3UU0/pfjqzwSly53qFSeTqOjolQKiE5jCgRPVV9+6qmz9Qmcg7/mys9TXUxptAqE= X-Gm-Message-State: AOJu0YyA3itNGzA4WtCIqa2Ua4kflTUvu7T/Az/LgvwnL6Co5dD64lmJ P2SqAx76c1ZC3JF4fg5jVMEKsvPOULMUJ8NJmpl97qmD/bk4YkayfQ/NiCvWcqDigM9kNpVP0L1 9mkOEsdTlV8Q/JB/7nLO3A6vbEVQ= X-Google-Smtp-Source: AGHT+IHzb6HnoMVI3r1GqPxQLXEhGuKId4eii5KClJVTeCaWMH8O8+/vBPtTjvTEFe5E/Xt5C82Qm206924KKl6tGjc= X-Received: by 2002:a05:6512:250:b0:523:90df:a9c6 with SMTP id 2adb3069b0e04-52b896da5f9mr4048302e87.50.1717324586739; Sun, 02 Jun 2024 03:36:26 -0700 (PDT) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 2 Jun 2024 10:36:26 +0000 In-Reply-To: <86ed9qyxnm.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:286377 Archived-At: Eli Zaretskii writes: >> > What about making `lm-version' handle the "package-version" header the= n >> > using `lm-version' in loaddefs-generate--parse-file? See patches. >> >> My main concern was if we want to have Package-Version always override >> Version, but if my patch modified loaddefs-gen, then I don't think there >> is much of a difference if we change lisp-mnt instead (in terms of the >> generality of the change). >> >> So I am fine with the change, and think we can merge it. Eli: Is master >> still fine for these kinds of changes? > > I think so, yes. But maybe I don't fully understand the effect of > this change? Can you describe it? > > I also added the other maintainers, in case they have opinions on > this. I think the first patch is right, i.e. to use (lm-version) instead of (lm-header "version") So let's install that one, I think. The effect of the second patch is to change `lm-version` to look for a "Package-Version" header if there is no "Version" header. This has two problems: 1. We didn't do that until now, and it's not clear to me what is the issue that is prompting this change. The transient.el issue seems to have been fixed already. 2. The way I read the manual, it seems like "Package-Version" should be preferred over "Version", if it exists: =E2=80=98Package-Version=E2=80=99 If =E2=80=98Version=E2=80=99 is not suitable for use by the pa= ckage manager, then a package can define =E2=80=98Package-Version=E2=80=99; it will = be used instead. This is handy if =E2=80=98Version=E2=80=99 is an RCS id or som= ething else that cannot be parsed by =E2=80=98version-to-list=E2=80=99. I'm also not sure we need to support packages with unusual versions like RCS id's these days. Is that use case still relevant? Perhaps we should simply deprecate the "Package-Version" header?