I rebuilt networkmanager locally and was greeted with this:
>>> Size difference for networkmanager: 16 MiB -> 2772 KiB
It turns out networkmanager-elogind provides networkmanager so apk info
will list both, and the former is much bigger so it looked like the
rebuilt package was much smaller when there was almost no difference (as
expected)
Fix by matching on exact package name for both lines; this is already
what we were doing with the local package anyway and the apk fetch
correctly picks the correct package in this case
Since the changeset committed by psykose a while ago in commit
26118d4997 we now extract the
previous soname. We can pass this previous soname to `apk search -R`
to figure out how many packages are linked against this old soname.
I believe this to be useful for reviewing MRs since the checkapk
output will directly tell us if a contributor has missed rebuilds.
It will also inform us when no rebuilds are necessary, e.g. if the
SONAME was changed but no packages is linked against the library.
Example output for `main/libsodium`:
```
>>> Size difference for libsodium: 336 KiB -> 340 KiB
--- filelist-libsodium-old 2023-09-22 11:24:54.799204225 +0200
+++ filelist-libsodium-new 2023-09-22 11:24:54.799204225 +0200
@@ -1,5 +1,5 @@
.PKGINFO
usr/
usr/lib/
-usr/lib/libsodium.so.23
-usr/lib/libsodium.so.23.3.0
+usr/lib/libsodium.so.26
+usr/lib/libsodium.so.26.1.0
SODIFF:
-usr/lib/libsodium.so.23.3.0: SONAME libsodium.so.23
+usr/lib/libsodium.so.26.1.0: SONAME libsodium.so.26
REBUILDS:
*** 36 packages linked against 'libsodium.so.23' need to be rebuild!
```
the previous implementation had a bug that + chars needed escaping
(which was fixed), and now has another discovered but that pkgnames
could start with a number, so the /^pkg/ match matches the pkgname again
and a size comparison gives you:
>>> Size difference for 7zip: 7zip-22.01-r5 installed size: -> 7zip-23.01-r0 installed size:
using grep -F avoids any magic character expansion and works correctly
in all cases.
prior to the recent reworks, this error handling path was never
triggered, because the script is ran without pipefail, and it was at
the end of a | pipe | line | sort, so all it did was be ignored for 'new
apks', when the old one would fail to fetch and be missing.
since we now do hit this path on fetch failure however, it aborts the
script when a new subpackage/package is added (since the 'old apk' won't
exist), and doesn't output a diff. since before we always ignored this,
ignore the 'old apk' perhaps not existing, which gives the currently
intended behaviour.
when apk fetch fails (a new package is added) these just say 'gzip invalid magic' or similar, as there is no old apk to compare to.
the || die is also never triggered, as it only triggers when the sort fails, since it won't trigger on earlier pipeline steps
this needs more cleaning up, but i'll leave that for the future when i write some tests.
Dominique Martinet
Natanael Copa
Sertonix
Sören Tempel
psykose
Leo
Jakub Jirutka
Timo Teräs
Dubiousjim