[PATCH 0/2] Polish module_directory help string, install symlinks

[PATCH 0/2] Polish module_directory help string, install symlinks

[Emil Velikov via B4 Relay]

Hello all,

I've noticed the recent module_directory work and I'm super hyped to see
it released. Are there any plans for v32?

This tiny series has two patches:
 - tweaks the help string for the module_directory toggle
 - installs the insmod, rmmod, lsmod ... symlinks

The above should be fairly straightforward, but if there's any questions
or concerns do let me know.

Thanks
Emil

---
Emil Velikov (2):
      configure: tweak the module_directory help string
      make: install/uninstall tools symlinks to kmod

 Makefile.am  | 10 ++++++++++
 configure.ac |  2 +-
 2 files changed, 11 insertions(+), 1 deletion(-)
---
base-commit: 48b0c75f79f86140314b9656d3d855a515e18a73
change-id: 20240126-master-5ba286b26eed

Best regards,
-- 
Emil Velikov <emil.l.velikov@gmail.com>

[PATCH 1/2] configure: tweak the module_directory help string

[Emil Velikov via B4 Relay]

From: Emil Velikov <emil.velikov@collabora.com>

Drop the somewhat misleading ${prefix}/lib/modules and explicitly
mention what's the default.

Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
---
 configure.ac | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index de01e08..ab0b303 100644
--- a/configure.ac
+++ b/configure.ac
@@ -93,7 +93,7 @@ AC_SUBST([rootlibdir], [$with_rootlibdir])
 
 # Ideally this would be $prefix/lib/modules but default to /lib/modules for compatibility with earlier versions
 AC_ARG_WITH([module_directory],
-        AS_HELP_STRING([--with-module-directory=DIR], [directory in which to look for kernel modules - typically '/lib/modules' or '${prefix}/lib/modules']),
+        AS_HELP_STRING([--with-module-directory=DIR], [directory in which to look for kernel modules @<:@default=/lib/modules@:>@]),
         [], [with_module_directory=/lib/modules])
 AC_SUBST([module_directory], [$with_module_directory])
 

-- 
2.43.0

[PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Emil Velikov via B4 Relay]

From: Emil Velikov <emil.velikov@collabora.com>

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@collabora.com>
---
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; \
+	done
+endif
 
 uninstall-hook:
 	rm -f $(DESTDIR)$(rootlibdir)/libkmod.so*
+if BUILD_TOOLS
+	for tool in insmod lsmod rmmod depmod modprobe modinfo; do \
+		rm -f $(DESTDIR)$(bindir)/$$tool; \
+	done
+endif
 
 if BUILD_TOOLS
 bin_PROGRAMS = tools/kmod

-- 
2.43.0

Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Lucas De Marchi]

On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:
>From: Emil Velikov <emil.velikov@collabora.com>
>
>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.

It was a long time ago and my memory may be fading, but afair the fact
that distros were doing it was what prevented us from adding the
symlinks ourselves.... and then we never re-visited this.

I'll dig some history before applying to make sure I'm not forgetting
something.

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


yes, I should be releasing that soon, probably this week or the next.

thanks
Lucas De Marchi

Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Emil Velikov]

On Mon, 29 Jan 2024 at 16:40, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>
> On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:
> >From: Emil Velikov <emil.velikov@collabora.com>
> >
> >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.
>
> It was a long time ago and my memory may be fading, but afair the fact
> that distros were doing it was what prevented us from adding the
> symlinks ourselves.... and then we never re-visited this.
>
> I'll dig some history before applying to make sure I'm not forgetting
> something.
>
Ack, makes sense. Fwiw I've already opened a MR with the Arch team
highlighting these changes.

Sadly I don't have contact for other maintainers.

> >
> >Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
> >---
> >Out of curiosity: are there any plans about releasing v32? I'm
> >interested in the recent /usr/lib/modules (module_directory) patches.
>
>
> yes, I should be releasing that soon, probably this week or the next.
>

Thanks much appreciated.
Emil

Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Lucas De Marchi]

On Mon, Jan 29, 2024 at 05:23:44PM +0000, Emil Velikov wrote:
>On Mon, 29 Jan 2024 at 16:40, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>>
>> On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:
>> >From: Emil Velikov <emil.velikov@collabora.com>
>> >
>> >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.
>>
>> It was a long time ago and my memory may be fading, but afair the fact
>> that distros were doing it was what prevented us from adding the
>> symlinks ourselves.... and then we never re-visited this.
>>
>> I'll dig some history before applying to make sure I'm not forgetting
>> something.
>>
>Ack, makes sense. Fwiw I've already opened a MR with the Arch team
>highlighting these changes.

no wonder my memory faded as it was almost 12 years ago and during  kmod 3 ~ 5.


00fc926 build-sys: create symlinks instead of building separate tools

	when we started using symlinks to a single kmod binary

7bbf523 build-sys: create symlinks if we are installing tools
12fd9cd build-sys: forcefully create links

	when we started creating the symlinks

fe8b067 build-sys: do not create symlinks by default

	stop creating the symlinks since it was not working across
	distros and creating more problems than solving

Now that distros configure all the paths through configure options,
we can probably re-attempt this.

Cc'ing some pkg maintainers


Lucas De Marchi

>
>Sadly I don't have contact for other maintainers.
>
>> >
>> >Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
>> >---
>> >Out of curiosity: are there any plans about releasing v32? I'm
>> >interested in the recent /usr/lib/modules (module_directory) patches.
>>
>>
>> yes, I should be releasing that soon, probably this week or the next.
>>
>
>Thanks much appreciated.
>Emil

Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Emil Velikov]

On Mon, 29 Jan 2024 at 22:09, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>
> On Mon, Jan 29, 2024 at 05:23:44PM +0000, Emil Velikov wrote:
> >On Mon, 29 Jan 2024 at 16:40, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> >>
> >> On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:
> >> >From: Emil Velikov <emil.velikov@collabora.com>
> >> >
> >> >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.
> >>
> >> It was a long time ago and my memory may be fading, but afair the fact
> >> that distros were doing it was what prevented us from adding the
> >> symlinks ourselves.... and then we never re-visited this.
> >>
> >> I'll dig some history before applying to make sure I'm not forgetting
> >> something.
> >>
> >Ack, makes sense. Fwiw I've already opened a MR with the Arch team
> >highlighting these changes.
>
> no wonder my memory faded as it was almost 12 years ago and during  kmod 3 ~ 5.
>
>
> 00fc926 build-sys: create symlinks instead of building separate tools
>
>         when we started using symlinks to a single kmod binary
>
> 7bbf523 build-sys: create symlinks if we are installing tools
> 12fd9cd build-sys: forcefully create links
>
>         when we started creating the symlinks
>
> fe8b067 build-sys: do not create symlinks by default
>
>         stop creating the symlinks since it was not working across
>         distros and creating more problems than solving
>
> Now that distros configure all the paths through configure options,
> we can probably re-attempt this.
>
> Cc'ing some pkg maintainers
>

Thanks for the information. Curiosity got the best of me, so I had a
look across few distros:

Arch - installs kmod in /usr/bin, symlinks are in /usr/bin.

Debian - installs kmod in /usr/bin and symlinks are split across
/usr/bin and /usr/sbin. Cannot find any references if they're aiming
to merge /usr/bin and /usr/sbin.

Fedora - installs kmod in /usr/bin and symlinks are split across
/usr/bin and /usr/sbin. Fedora 40 is aiming to "merge" /usr/bin and
/usr/sbin.

Gentoo - installs kmod in /bin and symlinks are split across /bin and
/sbin. Gentoo has merged /usr (/{,s}bin being a symlink to
/usr/{.s}bin) and merged bin (/usr/sbin is a symlink to /usr/bin in
some instances.
The https://wiki.gentoo.org/wiki/Merge-usr wiki explains the tool
aiming with merge conversions, although it seems to be optional albeit
highly(?) recommended.

TlDr: Distro variations still exist. Arch is fine, Fedora 40 should be
OK. Debian will need an in-package tweak. Gentoo will be fine for most
or at least some instances.

Personally (Arch user here) it makes sense to land and release this,
alongside the /usr/lib/modules support. Although if you think it makes
sense to defer for a later date, that's fine with me.

Regards,
Emil

Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Marco d'Itri]

On Jan 31, Emil Velikov <emil.l.velikov@gmail.com> wrote:

> Debian - installs kmod in /usr/bin and symlinks are split across
> /usr/bin and /usr/sbin. Cannot find any references if they're aiming
> to merge /usr/bin and /usr/sbin.
There are no such plans at this point.
I definitely will not be pushing for that, but somebody else might.

-- 
ciao,
Marco

Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Lucas De Marchi]

On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:
>From: Emil Velikov <emil.velikov@collabora.com>
>
>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@collabora.com>
>---
>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.

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?

thanks
Lucas De Marchi

Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Emil Velikov]

Hey Lucas,

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

Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Lucas De Marchi]

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 <lucas.demarchi@intel.com> wrote:
>>
>> On Fri, Jan 26, 2024 at 02:43:51PM +0000, Emil Velikov via B4 Relay wrote:
>> >From: Emil Velikov <emil.velikov@collabora.com>
>> >
>> >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@collabora.com>
>> >---
>> >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
>
>> 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

Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Emil Velikov]

On Mon, 5 Feb 2024 at 14:30, Lucas De Marchi <lucas.demarchi@intel.com> wrote:

[snip]

> >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 /.
>

That is true and I fully agree. Yet the contents of DESTDIR are not
meant to be run as-is - it's used for "staging" [1].

[1] https://www.gnu.org/software/make/manual/html_node/DESTDIR.html

> 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.
>

That sounds like a horrible bug, which can easily break your system
regardless of the project.

Would you consider dropping the leading `./` aka can we use `$(LN_S)
kmod $(DESTDIR)$(bindir)/$$tool;`?
Seems to be prevailing on my system with over 90% instances.

Thanks,
Emil

Re: Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Lucas De Marchi]

On Mon, Feb 05, 2024 at 05:50:54PM +0000, Emil Velikov wrote:
>On Mon, 5 Feb 2024 at 14:30, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>
>[snip]
>
>> >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 /.
>>
>
>That is true and I fully agree. Yet the contents of DESTDIR are not
>meant to be run as-is - it's used for "staging" [1].
>
>[1] https://www.gnu.org/software/make/manual/html_node/DESTDIR.html
>
>> 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.
>>
>
>That sounds like a horrible bug, which can easily break your system
>regardless of the project.
>
>Would you consider dropping the leading `./` aka can we use `$(LN_S)
>kmod $(DESTDIR)$(bindir)/$$tool;`?
>Seems to be prevailing on my system with over 90% instances.

seems good to me. I will squash that and push.

thanks
Lucas De Marchi


>
>Thanks,
>Emil

Re: Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Emil Velikov]

On Tue, 6 Feb 2024 at 16:15, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>
> On Mon, Feb 05, 2024 at 05:50:54PM +0000, Emil Velikov wrote:
> >On Mon, 5 Feb 2024 at 14:30, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
> >
> >[snip]
> >
> >> >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 /.
> >>
> >
> >That is true and I fully agree. Yet the contents of DESTDIR are not
> >meant to be run as-is - it's used for "staging" [1].
> >
> >[1] https://www.gnu.org/software/make/manual/html_node/DESTDIR.html
> >
> >> 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.
> >>
> >
> >That sounds like a horrible bug, which can easily break your system
> >regardless of the project.
> >
> >Would you consider dropping the leading `./` aka can we use `$(LN_S)
> >kmod $(DESTDIR)$(bindir)/$$tool;`?
> >Seems to be prevailing on my system with over 90% instances.
>
> seems good to me. I will squash that and push.
>

Respectful poke?

Thanks
Emil

Re: Re: Re: Re: [PATCH 2/2] make: install/uninstall tools symlinks to kmod

[Lucas De Marchi]

On Wed, Feb 14, 2024 at 04:22:44PM +0000, Emil Velikov wrote:
>On Tue, 6 Feb 2024 at 16:15, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>>
>> On Mon, Feb 05, 2024 at 05:50:54PM +0000, Emil Velikov wrote:
>> >On Mon, 5 Feb 2024 at 14:30, Lucas De Marchi <lucas.demarchi@intel.com> wrote:
>> >
>> >[snip]
>> >
>> >> >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 /.
>> >>
>> >
>> >That is true and I fully agree. Yet the contents of DESTDIR are not
>> >meant to be run as-is - it's used for "staging" [1].
>> >
>> >[1] https://www.gnu.org/software/make/manual/html_node/DESTDIR.html
>> >
>> >> 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.
>> >>
>> >
>> >That sounds like a horrible bug, which can easily break your system
>> >regardless of the project.
>> >
>> >Would you consider dropping the leading `./` aka can we use `$(LN_S)
>> >kmod $(DESTDIR)$(bindir)/$$tool;`?
>> >Seems to be prevailing on my system with over 90% instances.
>>
>> seems good to me. I will squash that and push.

sorry I went on vacations and didn't realize I hadn't pushed.
Now it's in and with the other patches fixing make distcheck
we are clear for a release.  I will prep that this week.

thanks
Lucas De Marchi

>>
>
>Respectful poke?
>
>Thanks
>Emil