Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: New utility: check-link-consistency (Read 1640 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

New utility: check-link-consistency

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.

Re: New utility: check-link-consistency

Reply #1 –
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
 

Re: New utility: check-link-consistency

Reply #2 –
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.

Re: New utility: check-link-consistency

Reply #3 –
Quote from: dimgel – on
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?
Once pkg gets installed, it doesn't know anything about DESTDIR or PREFIX, the binaries go into, in our case, /usr/bin
Quote
2. Why config is installed with -Dm755, wouldn't -Dm644 be more appropriate?
-Dm755 creates dir(if it doesn't exist) and makes the file executable
Quote
3. Why config is installed without extension?
Code: [Select]
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
Quote
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.
-- Ok, as long as it is normal, just thought I'd bring up what I seen during usage.

Re: New utility: check-link-consistency

Reply #4 –
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.

Re: New utility: check-link-consistency

Reply #5 –
Quote from: dimgel – on
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

Re: New utility: check-link-consistency

Reply #6 –
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. :)

Re: New utility: check-link-consistency

Reply #7 –
Quote from: dimgel – on
Ok, so PREFIX is for distro-specific stuff, and config is always in /etc no matter where binary goes to. Thanks for your patience. :)
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.

Re: New utility: check-link-consistency

Reply #8 –
Quote from: ndowens – on
Once pkg gets installed, it doesn't know anything about DESTDIR or PREFIX, the binaries go into, in our case, /usr/bin
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
Quote
Historically and strictly according to the standard, /usr/local is for data that must be stored on the local host (as opposed to /usr, which may be mounted across a network). Most of the time /usr/local is used for installing software/data that are not part of the standard operating system distribution (in such case, /usr would only contain software/data that are part of the standard operating system distribution). It is possible that the FHS standard may in the future be changed to reflect this de facto convention.

Re: New utility: check-link-consistency

Reply #9 –
> 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 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.

Re: New utility: check-link-consistency

Reply #10 –
Quote from: dimgel – on
> 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 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

Re: New utility: check-link-consistency

Reply #11 –
> Edit: It is now in the universe repo for others

Wow, thank you! :) Later I'll reflect this in install instructions in README.

Re: New utility: check-link-consistency

Reply #12 –
Code: [Select]
$ 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:
Code: [Select]
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.

Re: New utility: check-link-consistency

Reply #13 –
Quote from: ####### – on
When I tried to install python2-pip-git from the AUR then I got half a screenful of further dep problems:
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
Quote
Python 2.0 was released on 16 October 2000, with many major new features, including a cycle-detecting garbage collector (in addition to reference counting) for memory management and support for Unicode.[45]

Python 3.0 was released on 3 December 2008. It was a major revision of the language that is not completely backward-compatible.[46] Many of its major features were backported to Python 2.6.x[47] and 2.7.x version series. Releases of Python 3 include the 2to3 utility, which automates the translation of Python 2 code to Python 3.[48]

Python 2.7's end-of-life date was initially set at 2015 then postponed to 2020 out of concern that a large body of existing code could not easily be forward-ported to Python 3.[49][50] No more security patches or other improvements will be released for it.[51][52] With Python 2's end-of-life, only Python 3.6.x[53] and later are supported.

Python 3.9.2 and 3.8.8 were expedited[54] as all versions of Python (including 2.7[55]) had security issues, leading to possible remote code execution[56] and web cache poisoning.[57]

Re: New utility: check-link-consistency

Reply #14 –
> 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.