Remove embedded DESTDIR in make variables, honour them

[evelikov]

This series was inspired by a bunch of hardcoded paths across the project. The more i looked into the code, the bugs stared back at me ...

As a whole this series does a few closely related things:

• Removes a few seemingly broken and unused scripts
• No longer compresses the man page
• Removes some should-not-have-been-a-variable and unused-variable instances
• Removes the uncommon hard-coded DESTDIR prefix for variables
• Ensures the remaining variables are honoured across the board

In practical terms this means:

• find-provides, lsb_release and dkms_common.postinst (only user that I can find is Remove /usr/lib/dkms/common.postinst instances/handling openzfs/zfs#15175) (edit: keep dkms_common.postinst) are gone. @anbe42, @xnox, @scaronni others, I believe Debian Ubuntu and Fedora should not be affected by this removal. Can you give it a quick check on your end and let me know?
• The gzip manpage compression is left for builders/distros - @AndrewAmmerlaan you can drop the workaround from the Gentoo ebuild now
• setting VAR, ETC, BASHDIR, MAN, DOCDIR and SHAREDIR is no longer allowed - only Arch was setting one of these BASHDIR - to the default value nevertheless
• setting SYSTEMD, SBIN, LIBDIR and KCONF path does not need explicit DESTDIR prefix
• hardcoded paths are removed in favour of the SBIN, LIBDIR and KCONF variables - @scaronni @AndrewAmmerlaan

Some notes to the Arch maintainer @seblu (Arch task):

• the 4 year old PKGBUILD.26 can be removed
• the moddir patching aka s,/lib/modules,/usr/lib/modules,g should be dropped - we don't patch kmod either
• BASHDIR can be dropped, it's the default
• SBIN, KCONF and LIBDIR are relative to DESTDIR so they should be updated
• hook.sh should probably be reworked to use dkms autoinstall - happy to make autoinstall changes to make that possible edit: had a quick look, there's a lot more going on in hook.sh

Closes: #324

[Nowa-Ammerlaan]

• The gzip manpage compression is left for builders/distros - @AndrewAmmerlaan you can drop the workaround from the Gentoo ebuild now
  ...
• hardcoded paths are removed in favour of the SBIN, LIBDIR and KCONF variables - @scaronni @AndrewAmmerlaan

Great! Thanks for the heads-up.

[evelikov]

Correction: Debian packaging has some common.postinst references - namely 1 and 2 although I'm not sure if these Legacy use-cases are still applicable/relevant. The HowTo looks outdated.

@anbe42 feel free to forward ^^ to fellow maintainers.

[anbe42]

I believe the legacy support in dh_dkms can go away (just need to check that it is not used anymore by any package) and the howto should be dropped.

But installation of a *-dkms package calls /usr/lib/dkms/common.postinst from its postinst script to build the newly installed module for all installed kernel headers, so that script is still needed. And it is expected to exist by all existing *-dkms packages that depend on dkms >= 2.1

I'll look into this in more detail after holidays ...

[evelikov]

Sounds like it's better if we keep the script for now. Especially given its overall complexity, completely undocumented nature and the limited response (understandably) from core OpenZFS people.

Will open a separate MR for that yakshaving exercise ... and its companions.

[evelikov]

Modulo any objections I will be merging this on Friday.

[evelikov]

Whelp I guess it was my time to catch COVID. Somewhat recovered, let's merge this and enjoy any fallouts :-)

[AllKind]

@evelikov
As I was made aware here openzfs/zfs#15415 (comment), the way I implemented the dkms routines for ZFS do not work in chroot environment.
The only way to make it work I see is to reintroduce the use of common.postinst.
So I come here to ask if you have any other idea?

[evelikov]

@AllKind haven't used chroot in ages, so I don't recall all the gotchas.

We do have a task to make dkms chroot safe/happy - #145 - patches are very much welcome 😅

[AllKind]

@evelikov
I referenced #145...
The user says:

The chroot environment is an offline build of a virtual machine disk image and uses a different kernel from the host so installing those headers is not the solution. Other software using dkms does not have this problem and until recent 2.1.x versions zfs did not have an issue. We've been building this way since 0.6.x releases.

The common.postinst has handling exactly for the situation that the environment is a chroot:

if [ -z "$autoinstall_all_kernels" ]; then
    # If the current kernel is installed on the system or chroot
    if [ `_is_kernel_name_correct $CURRENT_KERNEL` = "yes" ]; then
        if [ -n "$NEWEST_KERNEL" ] && [ ${CURRENT_KERNEL} != ${NEWEST_KERNEL} ]; then
            KERNELS="$CURRENT_KERNEL $NEWEST_KERNEL"
        else
            KERNELS=$CURRENT_KERNEL
        fi
    # The current kernel is not useful as it's not installed
    else
        echo "It is likely that $CURRENT_KERNEL belongs to a chroot's host"

        # Let's use only the newest kernel if this is not a first installation
        # otherwise build for all kernels
        if [ -n "$NEWEST_KERNEL" -a -n "$UPGRADE" ]; then
            KERNELS="$NEWEST_KERNEL"
        fi
    fi
fi

---

So common.postinst can handle it somehow.
According to him it works in chroot.
The problem for me is, that I don't know a way in a post installation scriptlet, to tell dkms which kernel to use.
common.postinst has some logic to do that. How reliable that is, I don't know.
And I can't (doesn't really make sense) replicate all of common.postinst into the post installation scriptlet.
So I'm stuck with reverting my patch for zfs to use common.postinst?

Thanks for your input!

Edit: I never used chroot before, so I know like nothing about it :-(

[evelikov]

@AllKind can I ask you to open a new issue and add a very rough reproducer in there (if possible).

In the past I've seen cases where kernel arch/version isn't handled properly. Odds are this could be a either openzfs issue, dkms one or both.