On 03/26/19 at 10:42pm, Erich Eckner wrote:
On Wed, 27 Mar 2019, Allan McRae wrote:
On 27/3/19 7:20 am, Erich Eckner wrote:
https://mirror.pkgbuild.com/core/os/x86_64/core.links.tar.gz
It contains (as far as I can tell) the names and versions of libraries against which binaries in a package are linked.
This is not a repo, so should not be managed by repo-add.
Thanks for your answer, but:
Is the *.files.tar.gz a "repo"?
My interpretaion (so far) was, that the *.files.tar.gz and *.links.tar.gz files are caches for search accellerations inside the repo (the first for "who owns that file" and the second for "who links against that file") - is this not the case?
Also note, that managing the *.links.tar.gz file with repo-add would have benefits from a cleanness point of view: currently it's created asynchronously but it could be created synchronously (e.g. *.db.tar.gz, *.files.tar.gz and *.links.tar.gz would be always in-sync).
Furthermore, each downstream distribution wanting to have sogrep needs to implement the createlinks script asynchronously, too. This would become obsolete if it was part of repo-add.
I don't understand these arguments. sogrep is the only thing consuming these databases and no other uses have been proposed. Why can't sogrep provide a script to create its own databases that distributions can use in their tools at the same time they call repo-add? I'm not very familiar with them, but I know Arch has various scripts for building packages and managing repos; just have them call `buildlinksdb`, or whatever, immediately after repo-add.