GNU bug report logs - #60042
[PATCH] gnu: git: Update to 2.39.0.

Previous Next

Full log

Message #43 received at 60042 <at> debbugs.gnu.org (full text, mbox):

From: Simon Tournier <zimon.toutoune <at> gmail.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: Greg Hogan <code <at> greghogan.com>, 60042 <at> debbugs.gnu.org
Subject: Re: [bug#60042] What to call pinned package versions
Date: Wed, 11 Jan 2023 14:19:36 +0100

Hi,

On Mon, 09 Jan 2023 at 11:32, Simon Tournier <zimon.toutoune <at> gmail.com> wrote:

>  + Option a.
>
> version-control.scm:673:(define-public git-minimal/fixed -> git-minimal/pinned

[...]


>  + Option b.
>
> onc-rpc.scm:91:         (define libtirpc/fixed          -> libtirpc/grafted

[...]


>  + Option c. = option a. + option b. (remove reference to /fixed)
>
>
> From my point of view, option a. is the less “disruptive” because for
> instance we use the term “Fixes“ in commit message when a bug is indeed
> fixed.

Well, we also have another option:

   + Option d.: the version in the symbol; as in htslib-1.14.

   Considering the initial example,

     git-minimal/fixed    ->    git-minimal-2.33.1


This option d. appears to me the best:

 + it avoids ambiguity.

 + it is explicit – no need to grep for finding which version
 git-minimal/pinned refers to when reading Julia package recipes.

 + we are already doing that for multi-version packages.

Moreover, a ’default’ property could be also assigned to default
version (here the package defined by the symbol git-minimal).  And it
would allow to have less surprise when some multi versions package are
exported or incorrectly hidden.  See #60200 [1].

WDYT?

If we agree on Option d., then I could prepare a patch set and document
in the manual.  Let me know. :-)

1: <http://issues.guix.gnu.org/msgid/Y6LQs9+in964glaz <at> noor.fritz.box>


Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.