all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Simon Tournier <zimon.toutoune@gmail.com>
To: Distopico <distopico@riseup.net>, guix-devel@gnu.org
Subject: Re: Pinned versions should be a requirement.
Date: Thu, 07 Sep 2023 14:39:57 +0200	[thread overview]
Message-ID: <87h6o6kvhe.fsf@gmail.com> (raw)
In-Reply-To: <87h6o9pbbv.fsf@riseup.net>

Hi,

On Mon, 04 Sep 2023 at 21:59, Distopico <distopico@riseup.net> wrote:

> In my experience using Guix and attempting to make contributions, I've
> noticed that the vast majority of times when a library breaks, it's
> because one of its dependencies changed version.

That’s because contributor and/or reviewer are not running

    guix refresh -l foobar

for checking that all the dependants of foobar still build.  Well, there
is no easy solution, although QA is helping.  Note that this points is
not listed in the long list of Katherine,

        Re: How can we decrease the cognitive overhead for contributors?
        Katherine Cox-Buday <cox.katherine.e@gmail.com>
        Wed, 30 Aug 2023 10:11:02 -0600
        id:e47299e8-43f8-aac8-61ba-420daeb88bdd@gmail.com
        https://yhetil.org/guix/e47299e8-43f8-aac8-61ba-420daeb88bdd@gmail.com
        https://lists.gnu.org/archive/html/guix-devel/2023-08



>                                                  For instance,
> referencing something like `rust-my-lib-1`, where "1" refers to the
> semver "1.x" of the package, e.g., "1.0.32", and `rust-foo` depends on
> `rust-my-lib == 1.0.32`. However, in some other package got updated to
> "1.0.34" so `rust-foo` will break. I've seen this happen a lot with
> Haskell and Rust libraries.

Well, from my point of view, the issue depends on the upstream package
ecosystem.  Considering Haskell, we follow LTS, currently

        ;; Latest LTS version compatible with current GHC.
        (define %default-lts-version "20.5")

from the module (guix import stackage).  And note the lint checker,
“guix lint -l”:

    - haskell-stackage: Ensure Haskell packages use Stackage LTS versions


> For these reasons, I believe that pinned versions should be a
> requirement in libraries, always specifying the exact dependency, for
> example, `rust-serde-json-1.0.98`.

In the Subject: of the message, it reads pinned/fixed.  The difference
is:

  + 'pinned': version that rarely changes
  + 'fixed': mainly the ones with security fixes used as grafts

as discussed in [1].  Maybe you already know, it is just in case or for
other potential readers. :-)


> This brings the following benefits:

This issue that you are describing is not new and it often comes up.
The current consensus in order to detect such breaks is to apply patches
to the dedicated branch of the team.

In the case you are reporting, it seems that the changes should go first
to the rust-team branch and that branch should be merges once all
builds.

The workflow is not clearly established and still discussed.  We
collectively came up with a rough first draft at the last Guix Days back
on February.  Here some pointers,

        Discussion notes on releases and branches
        Andreas Enge <andreas@enge.fr>
        Thu, 09 Feb 2023 13:19:28 +0100
        id:Y+Tk0OKTyKKDqqlm@jurong
        https://yhetil.org/guix/Y+Tk0OKTyKKDqqlm@jurong
        https://lists.gnu.org/archive/html/guix-devel/2023-02

        Feature branches (was: 04/09: gnu: mesa: Update to 23.0.3)
        Andreas Enge <andreas@enge.fr>
        Mon, 08 May 2023 18:33:53 +0200
        id:ZFkkcQ2MOpku9YaF@jurong
        https://yhetil.org/guix/ZFkkcQ2MOpku9YaF@jurong
        https://lists.gnu.org/archive/html/guix-devel/2023-05

and the hope is that such workflow should act as your proposal but
without maintaining many variants (regular, /pinned and potential /fixed
for security fixes).


> Additionally, I believe that a command to list the dependency tree of a
> package would be ideal for easier debugging.

Do you mean “guix refresh -l”?

--8<---------------cut here---------------start------------->8---
$ guix refresh -l gmsh
Building the following 3 packages would ensure 4 dependent packages are rebuilt: openfoam-com@2212 python-pygmsh@7.1.17 openfoam-org@10.20230119
$ guix build $(guix refresh -l gmsh | cut -d':' -f2)
    … build all packages impacted by a change in the package gmsh …
--8<---------------cut here---------------end--------------->8---

Cheers,
simon


1: [bug#61078] [PATCH 0/4] Rename '/fixed' by '/pinned'
Simon Tournier <zimon.toutoune@gmail.com>
Thu, 26 Jan 2023 17:42:38 +0100
id:20230126164238.2462377-1-zimon.toutoune@gmail.com
https://yhetil.org/guix/20230126164238.2462377-1-zimon.toutoune@gmail.com
https://issues.guix.gnu.org/msgid/20230126164238.2462377-1-zimon.toutoune@gmail.com


  parent reply	other threads:[~2023-09-07 15:19 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-05  2:59 Pinned/fixed versions should be a requirement Distopico
2023-09-05 17:15 ` wolf
2023-09-07 12:39 ` Simon Tournier [this message]
2023-09-07 15:35   ` Pinned " Distopico
2023-09-09 10:39     ` Simon Tournier
2023-09-09 22:50 ` Pinned/fixed " Attila Lendvai
2023-09-09 23:30 ` Liliana Marie Prikler
2023-09-10  1:37   ` Distopico
2023-09-10  5:51     ` Liliana Marie Prikler
2023-09-27  7:51 ` Nguyễn Gia Phong via Development of GNU Guix and the GNU System distribution.

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

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

  git send-email \
    --in-reply-to=87h6o6kvhe.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=distopico@riseup.net \
    --cc=guix-devel@gnu.org \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.