https://github.com/dimgel/check-link-consistency
Analog of Gentoo's revdep-rebuild script, but better. =) Readme says it's for ArchLinux because someday it might find its way into AUR; but I use Artix, and sample config is my real working config on Artix.
The 'makefile' AFAIK, should be named Makefile. I may create a PKGBUILD for this later on
Also looking at the makefile, there needs to be DESTDIR and PREFIX used.
We don't use /usr/local for example. DESTDIR is used so during install files phase, it gets installed to a dir that gets packaged
I created a patch for makefile -> Makefile and add recommendations and use RELRO:
https://termbin.com/fzwx
Testing app, I've noticed maybe one thing to look at, example, thunderbird shows libmozgtk.so and others and pkgfile says that is owned by firefox, in which i do have installed.
In case you want to add a PKGBUILD for it: https://git.disroot.org/ndowens/PKGBUILDS/src/branch/master/check-link
I'll apply your patch tomorrow, but there are questions about config file:
1. How should app search for config then? (1.1) Should app embed DESTDIR and PREFIX it was compiled with? (1.2) Should I search config in DESTDIR/etc then in DESTRIR/PREFIX/share?
2. Why config is installed with -Dm755, wouldn't -Dm644 be more appropriate?
3. Why config is installed without extension?
> Testing app, I've noticed maybe one thing to look at, example, thunderbird shows libmozgtk.so and others and pkgfile says that is owned by firefox, in which i do have installed.
I don't get it. Too tired maybe. Well, libmozgtk.so is in both /usr/lib/firefox and /usr/lib/thunderbird, and they are different (which is natural since firefox and thunderbird versions don't have to match). So my sample config containing separate addLibPath directives for firefox and thunderbird is ok.
Once pkg gets installed, it doesn't know anything about DESTDIR or PREFIX, the binaries go into, in our case, /usr/bin
-Dm755 creates dir(if it doesn't exist) and makes the file executable
ls /usr/share/check-link-consistency/check-link-consistency.conf.sample
/usr/share/check-link-consistency/check-link-consistency.conf.sample
<- Shows how it is installed on my system after PKGBUILD used
It is installed as an example, as it is named sample. User can cp it into /etc as the correct conf name. ( in which, it should IMO, look for *.conf instead of *.conf.sample)
Simply cp /usr/share/check-link-consistency/check-link-consistency.conf.sample /etc/check-link-consistency.conf
-- Ok, as long as it is normal, just thought I'd bring up what I seen during usage.
Ok, I think I got it. DESTDIR is temporary "root" for packaging; forgot about it. So it's 100% irrelevant to config search.
But what PREFIX is for, then? Who would override it, why and with what? I mean, why DESTDIR is not enough? Just trying to understand packagers' kitchen. Also: if someone overrides it with /usr/local, then binary goes into /usr/local/bin but I still search config in /etc instead of /usr/local/etc. Weird. On the other hand, if PREFIX is not overriden, I would not search config in /usr/etc neither.
If you look at https://git.disroot.org/ndowens/PKGBUILDS/src/branch/master/check-link/0001-Fix-paths.patch#L46
it changes it from etc to usr/share/$APP_NAME , then the user can cp it from there to /etc with correct conf name(w/o .sample)
PREFIX, allows packagers to change / to be /usr /usr/local or whatever they want. Most Linux distro set prefix to /usr, while BSD uses /usr/local.
For the issue of config, maybe you can have it check for /etc/$APP_NAME.conf as that is the typical place to put configs.
So using PREFIX, if set to /usr then binaries go in /usr/bin and conf goes into /usr/share/$APP_NAME/$APP_NAME.conf.sample
Or if PREFIX is set to /usr/local it would be binaries in /usr/local/bin and etc. You could add in the Makefile to sed the app to where the config is, based on changes. Though can do something like add a
SYSCONFDIR variable that can be set to where conf should be and use that variable with sed to fix based on override
Ok, so PREFIX is for distro-specific stuff, and config is always in /etc no matter where binary goes to. Thanks for your patience. :)
> Though can do something like add a SYSCONFDIR variable
I'll keep things simple for now. :)
That is where ppl in Linux usually looks for to change, and look in /usr/share/* for example configs
Now if this worked on BSD, the Makefile would be near 100%, but since it uses pacman, makes it ALMOST pointless for the variables instead of hard setting where they go. I prefer to fix Makefiles into using variables to allow overrides if needed/wanted, so that is why I added those changes.
The reasoning behind this is the programs officially released by the distribution should be installed under /usr, and those installed by the user under /usr/local.
There's this bit of info as well:
https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#cite_note-11
> The reasoning behind this is the programs officially released by the distribution should be installed under /usr, and those installed by the user under /usr/local.
That I know. Just never considered my programs packaged, so wondered what it would look like and how to support both distro & user installations. Figures not worth trouble until requested.
Nathan, I commited (https://github.com/dimgel/check-link-consistency/commit/679320a9e54636e4e537c7e7c8e3ccc97317621c) your patch (figures -m755 is for file itself, so I did change it to -m644 for config) + corresponding README.md and main.cpp fixes. Don't want to study packaging right now, but if you'll package it as you suggested it would be fun.
Oh duh me, config should be 644 :D I think I was a little sleeply last night :D lol
Later I will probably add it to our universe repo, so others can use it
Edit: It is now in the universe repo for others
> Edit: It is now in the universe repo for others
Wow, thank you! :) Later I'll reflect this in install instructions in README.
$ sudo check-link-consistency
WARN Config file not found, using defaults.
INFO Analyzing installed packages...
INFO Scanning filesystem for bins & libs...
INFO Resolving libs...
INFO Downloading optional dependencies of problematic packages...
error: target not found: python2-pip
ERR PacMan_Arch:181: exec(pacman -Sw) failed: `/usr/bin/pacman` exited with status 1
Check IgnorePkg in /etc/pacman.conf.
Aborting: downloaded archives can be damaged.
When I tried to install python2-pip-git from the AUR then I got half a screenful of further dep problems:
error: unable to satisfy dependency 'python2-setuptools-scm' required by python2-pytest
error: unable to satisfy dependency 'python2-cachecontrol' required by python2-pip-git
for example - so perhaps python2-pip should be packaged as well, or check-link-consistency could be persuaded to use a current edition of python - obviously not if it was difficult to achieve. I'm sure these deps could be resolved by installing enough AUR packages but it seems a bit awkward to use at present. The -N flag bypassed these errors so it could give some output.
Python 2 is deprecated. Anything using Python 2 should be rewritten to use Python 3 instead. This is the official position of the development team.
https://en.wikipedia.org/wiki/Python_(programming_language)#History
> or check-link-consistency could be persuaded to use a current edition of python
It could not. :) It's not aware specifically of python or anything else. It just collects optional dependencies of installed packages containing broken files, then runs `pacman -Sw --noconfirm {list of those optional dependencies}`. You can see pacman's command line by running `check-link-consistency -v`. So error message comes from pacman itself and it means that you have installed something that lists python2-pip as (optional) dependency in `/var/lib/pacman/local/{your package}/desc`, and check-link-consistency passed that python-pip2 as is to pacman to download, but pacman cannot find it.
$ pacman -Si python2
Repository : world
Name : python2
Version : 2.7.18-5
...
Depends On : bzip2 expat gdbm libffi libnsl libxcrypt openssl sqlite zlib
Optional Deps : tk: for IDLE
python2-setuptools
python2-pip
...
Packager : Artix Build Bot <jenkins@artixlinux.org>
Build Date : Mon 11 Oct 2021 08:31:28 PM BST
It's the python2 package causing that problem, which is in the Artix repos. I also have postgresql installed which has python2 as an optional dep, so perhaps that's why it got installed, or it could have been added as a build dep for something. Thank you for answering that question, this seems very useful.
Optdeps don't get installed automatically. And check-link-consistency would not take postgres' optdeps if all postgres' own libs are good. You can try `check-link-consistency -O` to disable optdeps resolution and instantly see all broken libs. Note: there will be a lot of errors (false errors actually), and even more since you run without config file.
Ha, postgres indeed depends on py2.7, I just ran with `-O` option myself:
ERR postgresql 13.4-6 /usr/lib/postgresql/hstore_plpython2.so libpython2.7.so.1.0
ERR postgresql 13.4-6 /usr/lib/postgresql/jsonb_plpython2.so libpython2.7.so.1.0
ERR postgresql 13.4-6 /usr/lib/postgresql/ltree_plpython2.so libpython2.7.so.1.0
ERR postgresql 13.4-6 /usr/lib/postgresql/plpython2.so libpython2.7.so.1.0
ERR postgresql 13.4-6 /usr/lib/postgresql/pltcl.so libtcl8.6.so
Still, without `-O` option I never got errors about py2. Indeed pacman downloads python2 to resolve these:
# check-link-consistency -v 2>&1 | grep python2
EXEC /usr/bin/pacman -Sw --noconfirm ..... python2 .....
world/python2 2.7.18-5 76.87 MiB
EXEC /usr/bin/pacman -Sw --print-format '%n %l' python2
Yes, I think python2 was installed as a build dep for an AUR package checking back, not because of postgresql. python2 was already on my system, that was why check-link-consistency tried to install python2-pip and failed - it's the python2 PKGBUILD that contains an unresolvable (except by resorting to the AUR) optional dependency:
https://gitea.artixlinux.org/packagesP/python2/src/branch/master/x86_64/extra/PKGBUILD (https://gitea.artixlinux.org/packagesP/python2/src/branch/master/x86_64/extra/PKGBUILD)
But I can see why it's like that - after all, who would want to use some old version of python-pip, so why have it as a package, yet it's still accurate to say it's an optional dependency of python2!
Removing python2 resolved the errors and check-link-consistency ran without problems then.