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
next prev 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.