Hi,
On Mon, 04 Sep 2023 at 21:59, Distopico <distop...@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.katherin...@gmail.com>
Wed, 30 Aug 2023 10:11:02 -0600
id:e47299e8-43f8-aac8-61ba-420daeb88...@gmail.com
https://yhetil.org/guix/e47299e8-43f8-aac8-61ba-420daeb88...@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 <andr...@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 <andr...@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.touto...@gmail.com>
Thu, 26 Jan 2023 17:42:38 +0100
id:20230126164238.2462377-1-zimon.touto...@gmail.com
https://yhetil.org/guix/20230126164238.2462377-1-zimon.touto...@gmail.com
https://issues.guix.gnu.org/msgid/20230126164238.2462377-1-zimon.touto...@gmail.com
