unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Sylvain Bougerel <sylvain.bougerel.devel@gmail.com>
To: Philip Kaludercic <philipk@posteo.net>
Cc: 66985@debbugs.gnu.org
Subject: bug#66985: 29.1; Issue with `package.el` upgrading builtin (edge-case)
Date: Wed, 15 Nov 2023 21:06:38 +0800	[thread overview]
Message-ID: <CA+qKf8SzYm4S8XCaDz9+6jdbJRkjbKbaC5GTcMEuZ_DbajLn=w@mail.gmail.com> (raw)
In-Reply-To: <CA+qKf8TV1xnM1Qk1nXvU8nUC=cpHy4fMnimhcMB2k=BcyW+Sog@mail.gmail.com>

On Sat, Nov 11, 2023 at 1:05 AM Sylvain Bougerel
<sylvain.bougerel.devel@gmail.com> wrote:
> The issue occurs in the following scenario:
>     - Package A (version a), noted A(a), depends on packages B(z), then C(y)
>     - Package C(y) depends on package B(x), which is an _older_
> version than B(z)
>     - Neither A(a), B(z) nor C(y) are installed (the state of B(x) is
> irrelevant)
>

With a bit of time (est: a week or two), I can write a unit test and
make a patch with a better commit description that follows current
guidelines. Maybe the unit test will highlight the problem better? Let
me know if that will be appropriate/appreciated. My idea for the unit
test is to show that the sequence in which requirements are enumerated
should not have an effect on the resulting transaction, while it does
at the moment (in the specific case presented below - which is the
case I will test for).

      - Sylvain





  reply	other threads:[~2023-11-15 13:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07 13:11 bug#66985: 29.1; Issue with `package.el` upgrading builtin (edge-case) Sylvain Bougerel
2023-11-07 15:27 ` Sylvain Bougerel
2023-11-08  1:01   ` Sylvain Bougerel
2023-11-08  7:51 ` Philip Kaludercic
2023-11-08 16:30   ` Sylvain Bougerel
2023-11-10 17:05     ` Sylvain Bougerel
2023-11-15 13:06       ` Sylvain Bougerel [this message]
2023-11-15 13:30       ` Eli Zaretskii
2023-11-16  7:25       ` Philip Kaludercic
2023-11-17  9:37         ` Sylvain Bougerel
2023-11-27 17:18           ` Philip Kaludercic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+qKf8SzYm4S8XCaDz9+6jdbJRkjbKbaC5GTcMEuZ_DbajLn=w@mail.gmail.com' \
    --to=sylvain.bougerel.devel@gmail.com \
    --cc=66985@debbugs.gnu.org \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).