You are not logged in.
I have a question regarding the arch state repository at
https://gitlab.archlinux.org/archlinux/packaging/state
According to the documentation at
https://man.archlinux.org/man/alpm-state-repo.7.en
the hashes in the files are git commit SHA-1 hash digests
of the alpm-source-repo. I have trouble understanding what this
means. For example, the current (time of writing) file
https://gitlab.archlinux.org/archlinux/ … _64/netcdf
for the package 'netcdf' shows the following in the state repository:
netcdf 4.9.3-3 4.9.3-3 e89fee1c24eeec3d578df1d4157b73639411ad24but when I go the the package source repository
https://gitlab.archlinux.org/archlinux/ … ges/netcdf
I can't find the commit. Am I looking at the wrong repository,
or am I looking at the wrong type of hashes?
Also, if I look at the DEPENDS/MAKEDEPENDS etc. for the package 'netcdf' in
/var/lib/pacman/sync/*db
does this mean that the exact binaries of those dependencies as referenced in the
*.db files served as input to produce the binary package 'netcdf' that is refercenced in the
database?
I guess what I'm asking is: is there a small subset of binaries listed in the *.db
files, from which all other binaries listed in the same *.db files can be built from (in combination
with the build scripts or 'package sources' for the respective versions). I'm not asking
about exact bit-by-bit reproducibility, but just about the dependecy tree of the binary
inputs to the build process.
Thanks for our help!
Regards, Stefan
Last edited by stri (2025-11-16 12:16:52)
Offline
I just saw this post that answers the second question or least a related one
Are dependent packages in the repository rebuilt?
Offline
Moderator Note
Understanding or answering these questions requires in-depth knowledge of pacman and archlinux repo setup.
Moving to Pacman & Package Upgrade Issues.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
FWIW, this has nothing to do with pacman or the repo management scripts provided with pacman.
Offline
The man page linked comes from alpm-docs and archlinux pacman package provides libalpm .
Maybe someone could summarize the relation between upstream pacman and Arch Linux Package Management/libalpm ?
Last edited by Lone_Wolf (2025-11-08 13:46:54)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Offline
libalpm is part of the pacman codebase - it is the library that pacman (and some other package management frontends) is built upon.
The ALPM team has no relationship to pacman. AFAICT, they are paid to write utilities for interacting with pacman packages and databases in rust, but rarely if ever contribute to pacman/libalpm..
Offline
(sorry, I previously only glanced over your initial post and missed that you had already found the docs for the state repo format)
https://gitlab.archlinux.org/archlinux/ … _64/netcdf
for the package 'netcdf' shows the following in the state repository:
netcdf 4.9.3-3 4.9.3-3 e89fee1c24eeec3d578df1d4157b73639411ad24but when I go the the package source repository
https://gitlab.archlinux.org/archlinux/ … ges/netcdf
I can't find the commit. Am I looking at the wrong repository,
or am I looking at the wrong type of hashes?
You're indeed looking at the wrong hashes in the repo:
$ git ls-remote --tags --refs https://gitlab.archlinux.org/archlinux/packaging/packages/netcdf.git
[...]
e89fee1c24eeec3d578df1d4157b73639411ad24 refs/tags/4.9.3-3Regarding the previous comment by allan, the contribution of this manpage was done on a purely volunteer-base by me ![]()
Offline
Very good, thank you, I learned about the difference of annotated tags vs. "peeled" tags:
https://git-scm.com/book/en/v2/Git-Basics-Tagging
Also, the man page of git-ls-remote about the '--refs' option:
--refs
Do not show peeled tags or pseudorefs like HEAD in the output.
Offline