Hey Lucas,

On Fri, 2 Feb 2024 at 18:53, Lucas De Marchi [off-list ref] wrote:

On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:

quoted

From: Emil Velikov <redacted>

Currently we create symlinks like modprobe (pointing to kmod), during
the normal `make` build. Although those were never installed.

Add a few lines in the install-exec-hook, to ensure they're present at
`make install` time. Thus one can actually use those without additional
changes. As an added bonus, distributions can drop the similar hunk from
their packaging.

Signed-off-by: Emil Velikov <redacted>
---
Out of curiosity: are there any plans about releasing v32? I'm
interested in the recent /usr/lib/modules (module_directory) patches.

Thanks o/
---
Makefile.am | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/Makefile.am b/Makefile.am
index 4062d81..a22d1b1 100644
--- a/Makefile.am
+++ b/Makefile.am

@@ -111,9 +111,19 @@ install-exec-hook:
              ln -sf $$so_img_rel_target_prefix$(rootlibdir)/$$so_img_name $(DESTDIR)$(libdir)/libkmod.so && \
              mv $(DESTDIR)$(libdir)/libkmod.so.* $(DESTDIR)$(rootlibdir); \
      fi
+if BUILD_TOOLS
+      for tool in insmod lsmod rmmod depmod modprobe modinfo; do \
+              $(LN_S) $(bindir)/kmod $(DESTDIR)$(bindir)/$$tool; \

I was about to apply this, but then noticed a problem: I think we should
use a relative symlink here.

$ DESTDIR=/tmp/inst make install
$ ls -l /tmp/inst/usr/bin
total 700
lrwxrwxrwx 1 ldmartin ldmartin     13 Feb  2 12:44 depmod -> /usr/bin/kmod
lrwxrwxrwx 1 ldmartin ldmartin     13 Feb  2 12:44 insmod -> /usr/bin/kmod
-rwxr-xr-x 1 ldmartin ldmartin 715432 Feb  2 12:44 kmod
lrwxrwxrwx 1 ldmartin ldmartin     13 Feb  2 12:44 lsmod -> /usr/bin/kmod
lrwxrwxrwx 1 ldmartin ldmartin     13 Feb  2 12:44 modinfo -> /usr/bin/kmod
lrwxrwxrwx 1 ldmartin ldmartin     13 Feb  2 12:44 modprobe -> /usr/bin/kmod
lrwxrwxrwx 1 ldmartin ldmartin     13 Feb  2 12:44 rmmod -> /usr/bin/kmod

should had been e.g. depmod -> ./kmod

Simplest fix without resorting to calculating the shortest symlink is to
assume: the symlinks should be in the same dir as kmod, just like if
they were not symlinks.

I'm not sure I follow, can you elaborate what is the issue?

Are you trying to use/run files installed in DESTDIR directly? If so,
that won't work for a few reasons:
 - kmod does not link to the in-DESTDIR libkmod.so, admittedly one can
workaround it with LD_PRELOAD/LD_LIBRARY_PATH
 - kmod tries to open the depmod config files in the normal
non-DESTDIR locations

I'm not a huge fan of using relative symlinks, especially if the tool
is run as root. In my experience that makes things harder to audit and
prevent accidental breakages.

As an example, my Arch box has the following:

 - /usr/bin/init -> ../lib/systemd/systemd
 - /usr/bin/ld.so -> ../lib/ld-linux-x86-64.so.2
Hmm should probably see if we can change these and how many things will break

 - /usr/bin/lirc-setup -> ../lib/python3.11/site-packages/lirc-setup/lirc-setup
Modern practises are to have a shim in /usr/bin/

 - /usr/bin/slapacl -> ../lib/slapd
 - /usr/bin/slapadd -> ../lib/slapd
 - moar slapd
Hmm what is openldap doing on this system again


In other words - I'd love it if we don't use relative symlinks if
there are other options.

Thanks,
Emil