today my systems received an update to cryptsetup. Being this a package strongly related to the privacy and security of a system, I tried to check what was changed in the 2.6.1-3.4 → 2.6.1-3.5, but this appears to be impossible to do.
The package appears to be derived from arch, but not to be the arch package, since arch directly went from 2.6.1-3 to 2.7.0-1. However, it is not available on the manjaro’s gitlab in the core folder.
Where is the actual pkgbuild of the package to be found? Without it, it’s impossible to know what went into a binary package, if something was patched wrt to arch or to the upstream source, what and why.
When the pkgrel is a decimal it is usually because some upstream issue has caused the team to build an overlay package to shield the community from the upstream issue.
But I agree - in principle - we should have a separate repo for overlay packages.
The package in unstable is
$ pamac info cryptsetup
Name : cryptsetup
Version : 2.7.0-1
[...]
Packager : Christian Hesse <eworm@archlinux.org>
Build Date : ons 24 jan 2024 11:43:10 CET
Install Date : tir 30 jan 2024 09:38:05 CET
[...]
AFAIK that is the same version (before the -) only a newer build (the 3.4 vs the 3.5 after the -) so nothing to worry about, really. AFAIK the build number is unique to Manjaro, and any and all matches are purely coincidental.
Not sure I have understood everything. Trying to recap. Please, someone correct me if I am wrong:
Packages taken from arch do not typically appear in Manjaro’s gitlab. This is why cryptsetup is not there (apart from the older archived thing).
The reason why the pkgrel changes is when the package is rebuilt. @Mirdarthos you say ‘there is nothing to worry about because the package is the same version’ (I suppose this means the upstream version is the same). Why one should not be interested in knowing what has changed is unclear to me, though. A rebuild may involve a change in the PKGBUILD script which potentially can change a lot of things because it can patch the package, change the build configurables, etc.
For packages taken from arch, the pkgrel may change and get misaligned with the one in arch, it is because it was a Manjaro team to build an overlay to fix some issue. In this case, the pkgrel is decimal as it is in the current case. If something is fixed by means of modifying the PKGBUILD e.g. to force the source to be patched in some new way, I think that in this case it would be particularly precious to be able to see the PKGBUILD and (if any) the new patch.
@linux-aarhus It is my understanding that as of today there is no shared repo for these overlay packages. Where do they live? Do they remain on the personal machines of the members of the team producing such overlays? Wouldn’t it be better to have them also in the gitlab? Would it be difficult, according to the current process, to have them archived in the Manjaro gitlab?
@Mirdarthos From one of your comments, I understand that pkgrel may get bumped also as a consequence of rebuilds where nothing at all is actually changed and that get triggered because of changes in other packages. Your post suggests that this is the case now, i.e. that cryptsetup 2.6.1-3.5 is obtained from the exactly same sources as 2.6.1-3.4 and of arch’s 2.6.1-3, including the PKGBUILD (obviously I cannot check this because the PKGBUILD is not available). In fact, it seems to suggest that the 2.6.1-3.5 got built because this action was triggered by a kernel update. This is a bit unclear to me. Why should a kernel update have triggered a rebuild of cryptsetup. A kernel mantra is that Linux does not break userspace, so the same build of cryptsetup should have worked just fine with a newer kernel. In any case, it seems reasonable that when a dependency is updated a package gets automatically rebuilt with a bump in the pkgrel.
Would be great if there was some convention to understand the reason for a new pkgrel, though. E.g.
pkgrel bumped from 3.1 → 3.2 => This is an arch package that got a new overlay with modifications in the PKGBUILD or in some patch. The new Manjaro sauce will be available at…
pkgrel bumped from 3.1 to 3.1.1 => This is a rebuild with no source changes including no changes in the PKGBUILD. Hence it was a rebuild triggered by an update in some dependency.
There is, you just have to read it:
(from archwiki)
pkgrel
The release number. This is usually a positive integer number that allows to differentiate between consecutive builds of the same version of a package. As fixes and additional features are added to the PKGBUILD that influence the resulting package, the pkgrel should be incremented by 1. When a new version of the software is released, this value must be reset to 1. In exceptional cases other formats can be found in use, such as major.minor.
If it’s build by manjaro, then it’s not an arch package. You can check who is the packager of any package. And this major.minor pkgrel is a good indication it’s a manjaro package, since I have yet to see an arch package that uses anything but integers for pkgrel.
Why it’s not in manjaro’s gitlab? Ask @philm I guess.
It is a regular rebuild with no changes. Back then we hold back systemd. Was regarding this issue: Breaking change in cryptsetup 2.6.1-3. Currently in Berlin and not in Vietnam, where my other work laptop is at home. Also Lunar New Years festivals are coming, so I’ll be less active these days.
Still thinking that having a gitlab entry for anything that gets rebuilt by Manjaro (even if without any change) to have a log entry (e.g. git log entry) would be helpful to track things, without needing so many people to be involved and their time being used.