[PR PATCH] alsa-lib: update to 1.2.3.2.

[PR PATCH] alsa-lib: update to 1.2.3.2.

[ailiop-git]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

There is a new pull request by ailiop-git against master on the void-packages repository

https://github.com/ailiop-git/void-packages alsa-lib
https://github.com/void-linux/void-packages/pull/23713

alsa-lib: update to 1.2.3.2.


A patch file from https://github.com/void-linux/void-packages/pull/23713.patch is attached

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: github-pr-alsa-lib-23713.patch --]
[-- Type: text/x-diff, Size: 1061 bytes --]

From 2fe8c0c8bde362e4676132cf130e86de40fbefb9 Mon Sep 17 00:00:00 2001
From: Anthony Iliopoulos <ailiop@altatus.com>
Date: Wed, 22 Jul 2020 12:07:50 +0200
Subject: [PATCH] alsa-lib: update to 1.2.3.2.

---
 srcpkgs/alsa-lib/template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/srcpkgs/alsa-lib/template b/srcpkgs/alsa-lib/template
index 027a431dcef..7b9c46f0695 100644
--- a/srcpkgs/alsa-lib/template
+++ b/srcpkgs/alsa-lib/template
@@ -1,6 +1,6 @@
 # Template file for 'alsa-lib'
 pkgname=alsa-lib
-version=1.2.3.1
+version=1.2.3.2
 revision=1
 build_style=gnu-configure
 hostmakedepends="pkg-config libtool"
@@ -9,7 +9,7 @@ maintainer="Anthony Iliopoulos <ailiop@altatus.com>"
 license="LGPL-2.1-or-later"
 homepage="http://www.alsa-project.org"
 distfiles="https://www.alsa-project.org/files/pub/lib/${pkgname}-${version}.tar.bz2"
-checksum=1244585515fbebce7d0e53656c1fb614f99accb8413115ce3efb9a9309c4c892
+checksum=e81fc5b7afcaee8c9fd7f64a1e3043e88d62e9ad2c4cff55f578df6b0a9abe15
 patch_args="-Np1"
 
 alsa-lib-devel_package() {

Re: alsa-lib: update to 1.2.3.2.

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/23713#issuecomment-662498707

Comment:
You have other PRs, like an `mpg123` update, that link against `alsa-lib-devel`. While it might not matter for shlib compatibility, in the future, please combine things like `alsa-lib` and dependants like `mpg123` in a single PR with commits ordered to ensure that the new `alsa-lib` is built before anything that builds against it.

Re: [PR PATCH] [Merged]: alsa-lib: update to 1.2.3.2.

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 162 bytes --]

There's a merged pull request on the void-packages repository

alsa-lib: update to 1.2.3.2.
https://github.com/void-linux/void-packages/pull/23713

Description:

Re: alsa-lib: update to 1.2.3.2.

[ailiop-git]

[-- Attachment #1: Type: text/plain, Size: 568 bytes --]

New comment by ailiop-git on void-packages repository

https://github.com/void-linux/void-packages/pull/23713#issuecomment-662505684

Comment:
> You have other PRs, like an `mpg123` update, that link against `alsa-lib-devel`. While it might not matter for shlib compatibility, in the future, please combine things like `alsa-lib` and dependants like `mpg123` in a single PR with commits ordered to ensure that the new `alsa-lib` is built before anything that builds against it.

Since there's no shlib compatibility issue, why should those updates be combined? 

Re: alsa-lib: update to 1.2.3.2.

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 962 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/pull/23713#issuecomment-662517111

Comment:
The shlib dependency resolution in XBPS and xbps-src helps prevent a lot of problems, but that doesn't mean subtle issues can't appear when one updates a library and its headers but doesn't rebuild against the new version. Even if there are no problems, it's possible that the build objects can differ in some meaningful way when built against an older version of the library, which means versions built by xbps-src after the library is updated will be different than the official binary packages for no apparent reason.

Obviously we accept this tradeoff every time we update a library because revbumping every dependant of every library "just in case" isn't worth the cost. But if you're updating a dependent and a library within a few hours of one another, why not ensure proper ordering just to ensure consistency?