On Mon, Feb 05, 2024 at 12:37:42PM +0000, Emil Velikov wrote:

Hey Lucas,

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

quoted

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:

no, those would usually be done by setting prefix and sysconfdir

- 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

quoted

diff --git a/Makefile.am b/Makefile.am
index 39a46f4..6df2f60 100644
--- a/Makefile.am
+++ b/Makefile.am

@@ -113,7 +113,7 @@ install-exec-hook:
         fi
  if BUILD_TOOLS
         for tool in insmod lsmod rmmod depmod modprobe modinfo; do \
-               $(LN_S) $(bindir)/kmod $(DESTDIR)$(bindir)/$$tool; \
+               $(LN_S) ./kmod $(DESTDIR)$(bindir)/$$tool; \
         done
  endif

does that seem ok squashed on your patch?

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.

I'm completely in the opposite camp. Relative symlinks actually make
sure the thing you are running is what you are expecting. Nothing should
really point outside of $prefix expecting that is mounted on /.

Several years back there was also the issue with packaging, which would
complain when symlinks pointed outside what was being packaged.  It is
dangerous when using absolute symlinks because if the tool used to copy
follows the symlinks, it ends up with the wrong binary, copying the host
bin rather than what was just built.

Lucas De Marchi

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