Hey Lucas, On Fri, 2 Feb 2024 at 18:53, Lucas De Marchi <lucas.demarchi@xxxxxxxxx> wrote: > > On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote: > >From: Emil Velikov <emil.velikov@xxxxxxxxxxxxx> > > > >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 <emil.velikov@xxxxxxxxxxxxx> > >--- > >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 > 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. 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
