Distro inspired patches

[evelikov]

The final batch of converting quirks that distros have been using into upstream material.

The first patch is potentially a bit controversial - install the symlinks into sbin. As the commit message says - this is a functional no-op* for merged bin-sbin (and merged-usr) but on split setups, this means we do 60% of the time what 100% of distros do (Gentoo has lsmod and modinfo symlinks in {/usr,}/bin, Debian only lsmod, Fedora has neither).

The other two commits are fairly trivial though :sweat_smile:

[a] The meson install_symlink does not do --relative so we get the full path, even if the files are in the same directory.

@eli-schwartz can I offer some virtual :cookie: in exchange of getting a flag "use-relative" like flag to meson' install_symlink()?

[eli-schwartz]

@eli-schwartz can I offer some virtual 🍪 in exchange of getting a flag "use-relative" like flag to meson' install_symlink()?

https://mesonbuild.com/Fs-module.html#relative_to

Since 1.3.0 you can use fs = import('fs'); relative_bindir = fs.relative_to(bindir, sbindir)

[lucasdemarchi]

For the distros that still have sbin/bin, I think it's up to them to duplicate the kmod binary in both places and then keep the symlinks as they wish. A symlink from sbin to bin only proves this is stupid.

[lucasdemarchi]

[a] The meson install_symlink does not do --relative so we get the full path, even if the files are in the same directory.

which is wrong and breaks when you are are cross-compiling or installing on a tmpdir and testing with LD_LIBRARY_PATH, or does it also includes DESTDIR in the abspath?

[evelikov]

For the distros that still have sbin/bin, I think it's up to them to duplicate the kmod binary in both places

No distribution does this. Sorry if my comment suggested anything like that.

[evelikov]

which is wrong and breaks when you are are cross-compiling or installing on a tmpdir and testing with LD_LIBRARY_PATH, or does it also includes DESTDIR in the abspath?

Cannot really answer here since there are two use-cases mentioned with very very limited details. I could try and guess the missing pieces but that won't be productive.

[lucasdemarchi]

For the distros that still have sbin/bin, I think it's up to them to duplicate the kmod binary in both places

No distribution does this. Sorry if my comment suggested anything like that.

No, I meant what could be done. Just symlinking something from sbin to bin just doesn't make any sense and proves those shouldn't be separate... it stopped making sense long ago when we blurred the line between "normal binaries and sysadmin binaries".

If we have kmod depmod ... and kmod lsmod in addition to the symlinks, where are those distros going to put the kmod binary?

[eli-schwartz]

The issue is e.g. /sbin/modprobe is an "API filename" -- it must exist because that is the absolute pathname embedded into the linux kernel. The kernel doesn't perform a lookup on $PATH.

If the "kmod" program is installed to bindir instead of sbindir, then installing "modprobe" to bindir also, doesn't work. If it is desirable for "kmod" to be in the default directory for bins, and that is /bin rather than /sbin, then you suddenly need to become aware of whether the installation environment has sbin as a symlink to bin, or not.

If they do not symlink, then you're basically saying they are foolish for not understanding how brilliant and superior symlinking is. Meanwhile they are saying "you broke the operating system" and then they will manually work around your layout and not care about your opinions about sbin merging.

If we have kmod depmod ... and kmod lsmod in addition to the symlinks, where are those distros going to put the kmod binary?

They put kmod in /bin and modprobe in /sbin, and (at least on Gentoo) put the other binaries that do modifications such as depmod, insmod, rmmod in /sbin as well. modinfo is in /bin just like "kmod".

FWIW Gentoo supports both split and merged directories and I'm quite happy with the merged layout. I just know that the split layout exists and failure to support it will ruin the day of anyone with such an existing install.

[evelikov]

Some illustrative examples from distros. Existence of /usr is irrelevant for this and thus omitted.

Gentoo - lsmod and modinfo symlinks are alongside /bin/kmod, the rest are in /sbin

$ la /bin
kmod
lsmod -> kmod
modinfo -> kmod
$ la /sbin
depmod -> ../bin/kmod
insmod -> ../bin/kmod
modprobe -> ../bin/kmod
rmmod -> ../bin/kmod

Debian, Yocto - lsmod symlink is alongside /bin/kmod, the rest are in /sbin

$ la /bin
kmod
lsmod -> kmod
$ la /sbin
depmod -> ../bin/kmod
insmod -> ../bin/kmod
modinfo -> ../bin/kmod
modprobe -> ../bin/kmod
rmmod -> ../bin/kmod

Fedora, Alpine - all symlinks are in /sbin

$ la /bin
kmod
$ la /sbin
depmod -> ../bin/kmod
insmod -> ../bin/kmod
lsmod -> ../bin/kmod
modinfo -> ../bin/kmod
modprobe -> ../bin/kmod
rmmod -> ../bin/kmod

Basically, with the first commit (once fixed) - Fedora and Alpine will need zero quirks, Debian/Yocto 1, and Gentoo 2. While also having no effect on merged bin-sbin platforms. Debian recently picked a local patch similar to this one.

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

[evelikov]

v2:

• switch meson to add_install_script
• use ln --relative ...
• handle both meson and autotools

[lucasdemarchi]

The issue is e.g. /sbin/modprobe is an "API filename" -- it must exist because that is the absolute pathname embedded into the linux kernel. The kernel doesn't perform a lookup on $PATH.

it hasn´t been for a long time. It's a kernel build-time configuration, and there's also a runtime one.

If they do not symlink, then you're basically saying they are foolish for not understanding how brilliant and superior symlinking is.

No, this is not what I'm saying. What I'm saying is: what's the point of the split from the kmod/modprobe/depmod pov. Why is depmod a "system binary"? Consider for example developers preparing a build - what makes depmod special that they can't call it? Worse: depmod is just a symlink to a binary that is in the normal path. Things like this get workarounded in every single project. See for e.g.

commit cedd1862be7e666be87ec824dabc6a2b05618f36
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Dec 28 11:40:22 2020 -0800

    depmod: handle the case of /sbin/depmod without /sbin in PATH

Meanwhile they are saying "you broke the operating system" and then they will manually work around your layout and not care about your opinions about sbin merging.

I'm talking about kmod binaries being in one place or the other and how that doensn't make sense anymore? What exactly is breaking?

[lucasdemarchi]

@evelikov now we have this tree:

/tmp/testinstall/usr $ tree .
.
├── bin
│   └── kmod
├── include
│   └── libkmod.h
├── lib
│   ├── depmod.d
│   ├── libkmod.so -> libkmod.so.2
│   ├── libkmod.so.2 -> libkmod.so.2.5.0
│   ├── libkmod.so.2.5.0
│   ├── modprobe.d
│   └── pkgconfig
│       └── libkmod.pc
├── sbin
│   ├── depmod -> ../bin/kmod
│   ├── insmod -> ../bin/kmod
│   ├── lsmod -> ../bin/kmod
│   ├── modinfo -> ../bin/kmod
│   ├── modprobe -> ../bin/kmod
│   └── rmmod -> ../bin/kmod

So... by default we only install kmod in bin/ and all the rest in sbin/. That seems closer to what Ubuntu and Fedora do and away to what e.g. Archlinux does... which IMO is saner.

$ pacman -Ql kmod | grep bin
kmod /usr/bin/
kmod /usr/bin/depmod
kmod /usr/bin/insmod
kmod /usr/bin/kmod
kmod /usr/bin/lsmod
kmod /usr/bin/modinfo
kmod /usr/bin/modprobe
kmod /usr/bin/rmmod
kmod /usr/share/man/man5/modules.dep.bin.5.gz

So for Arch, they would still probably disable all symlinks and do the symlink themselves.

[evelikov]

@lucasdemarchi Arch has the /usr/bin/arch-meson wrapper (and other distros have equivalents) to appropriately set --sbindir /usr/bin. So the result is virtually the same from an Arch POV across the board*.

[lucasdemarchi]

Applied, thanks