[bug#77651,c++-team,1/1] gnu: Update abseil-cpp and abseil-cpp-20220623.
Commit Message
* gnu/packages/cpp.scm (abseil-cpp): Update to 20250127.1.
(abseil-cpp-20220623): Rename from abseil-cpp-20220623.1 and update to
20220623.2.
Change-Id: Ib695da324a70b0c55ec455b19861b7406ed44c9a
---
gnu/packages/cpp.scm | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
Comments
Hello Greg,
as usual, I would suggest a patch series of two commits, one per package;
these would be pushed together, so it does not really matter that both
need to be updated in lockstep. (This is not really different from what
is done on the python-team branch, for instance, where often updating
python-abc also requires to update python-xyz and python-123, but still
we use one commit per package.)
Andreas
On Tue, Apr 8, 2025 at 3:14 PM Andreas Enge <andreas@enge.fr> wrote:
>
> Hello Greg,
>
> as usual, I would suggest a patch series of two commits, one per package;
> these would be pushed together, so it does not really matter that both
> need to be updated in lockstep.
This patch does break cleanly into three patches, one for the rename
and two for the simple updates.
> (This is not really different from what
> is done on the python-team branch, for instance, where often updating
> python-abc also requires to update python-xyz and python-123, but still
> we use one commit per package.)
You and Maxim should discuss this, whether in general it is preferred
to make one commit per package or to combine commits to prevent
breakage in between. The latter does better allow users to
time-machine anywhere in the history but can require very large
commits and that contributors track down and apply fixes on branches
at the point of the breaking change.
> Andreas
Greg
Am Tue, Apr 08, 2025 at 04:37:33PM -0400 schrieb Greg Hogan:
> You and Maxim should discuss this, whether in general it is preferred
> to make one commit per package or to combine commits to prevent
> breakage in between.
Well, Guix practice, as far as I know, has always been to use one commit
per package. Did Maxim suggest otherwise, or why should we discuss it?
Andreas
On Tue, Apr 8, 2025 at 4:41 PM Andreas Enge <andreas@enge.fr> wrote:
>
> Am Tue, Apr 08, 2025 at 04:37:33PM -0400 schrieb Greg Hogan:
> > You and Maxim should discuss this, whether in general it is preferred
> > to make one commit per package or to combine commits to prevent
> > breakage in between.
>
> Well, Guix practice, as far as I know, has always been to use one commit
> per package. Did Maxim suggest otherwise, or why should we discuss it?
>
> Andreas
Discussion was part of #76960: https://issues.guix.gnu.org/76960#24
And I think I understand Maxim's point of view and am in agreement at
some level. My chief remark is that I don't see the project following
this practice, and that it is largely impractical to do so. But
perhaps we should do more of this where we can. Or instead simply do
(on the order of) quarterly releases.
I have seen, and have been writing, single commits which apply the
same very simple changes to multiple packages (for example, from
#76960 the pinning of the spdlog input).
Greg
Hello,
Am Wed, Apr 09, 2025 at 11:18:01AM -0400 schrieb Greg Hogan:
> I have seen, and have been writing, single commits which apply the
> same very simple changes to multiple packages (for example, from
> #76960 the pinning of the spdlog input).
I see; but think this is a different case. There you apply the same
change to different packages (swap one input for another one). One could
still do this one commit after another, but I also see the point in
doing a "mass" commit (well, I would rather do this if really many
packages were concerned).
In this case, you update two different packages to two different
versions. So I would argue that this is not the same situation, just
that they are linked. But this is also true when updating python-numpy
and following its dependency chain, and we do not use one giant commit
updating lots of packages in the python-team branch.
I would, however, combine your first two patches of the v2 :)
Your choice!
Andreas
@@ -1910,12 +1910,12 @@ (define-public abseil-cpp-20211102.0
((#:configure-flags flags)
#~(cons* "-DCMAKE_CXX_STANDARD=11" #$flags)))))))
-(define-public abseil-cpp-20220623.1
+(define-public abseil-cpp-20220623
(let ((base abseil-cpp-20200923.3))
(package
(inherit base)
(name "abseil-cpp")
- (version "20220623.1")
+ (version "20220623.2")
(source (origin
(method git-fetch)
(uri (git-reference
@@ -1924,7 +1924,7 @@ (define-public abseil-cpp-20220623.1
(file-name (git-file-name name version))
(sha256
(base32
- "0vxh2a74g4s45yr8kdjqnzl64k10qdlc0hbnn987a4cnwdj4bp9r"))
+ "1cmchfcqp85yp5hc3i47xv3i14v0f2wd5h2jblvcjjmjyhji1bwr"))
(patches
(search-patches "abseil-cpp-20220623.1-no-kepsilon-i686.patch"))))
(arguments
@@ -1934,11 +1934,11 @@ (define-public abseil-cpp-20220623.1
(delete "-DABSL_RUN_TESTS=ON" ,flags))))))))
(define-public abseil-cpp
- (let ((base abseil-cpp-20220623.1))
+ (let ((base abseil-cpp-20220623))
(package
(inherit base)
(name "abseil-cpp")
- (version "20240722.0")
+ (version "20250127.1")
(source (origin
(method git-fetch)
(uri (git-reference
@@ -1947,7 +1947,7 @@ (define-public abseil-cpp
(file-name (git-file-name name version))
(sha256
(base32
- "1pmrigimzic2k3ix3l81j2jpfgjgbajz0qbc5s57zljr2w7fjn77"))
+ "0r2j360csym12jlgmcy92rgwdmng63shchxvfmln3j5402lv0g21"))
(patches
(search-patches "abseil-cpp-20220623.1-no-kepsilon-i686.patch"))))
(arguments
@@ -2057,7 +2057,7 @@ (define-public abseil-cpp-cxxstd17
(abseil-cpp-for-c++-standard abseil-cpp 17)) ;XXX: the default with GCC 11?
(define-public abseil-cpp-cxxstd11
- (abseil-cpp-for-c++-standard abseil-cpp-20220623.1 11)) ;last version on C++11
+ (abseil-cpp-for-c++-standard abseil-cpp-20220623 11)) ;last version on C++11
(define-public static-abseil-cpp
(make-static-abseil-cpp abseil-cpp))