Dear Maintainer,

It appears that dkms upstream has removed support for mkdeb, mkdsc and
mkbmdeb --
https://github.com/dell/dkms/commit/68b083eaa3f71c166adfece8e4f760e0cdf96185

From that commit one can't really see if there have been any
discussions.

With the new upstream version arriving in unstable, it is not clear what
is now the proper way to create binary-only module packages, for
example? Our packaging seems to assume that all the support is still
there in upstream..


With best regards,
jaak.

control: forwarded -1 https://github.com/dell/dkms/issues

Hello, please consider joining the upstream discussion or open a defect there.

G.

The commit message for https://github.com/dell/dkms/commit/68b083eaa3f71c166adfece8e4f760e0cdf96185 says:

    "Distributions know much better than us, what is the proper
    way to package a DKMS module. Remove in-tree, semi-constantly
    out-of-date code."

and a comment on https://github.com/dell/dkms/issues/70 says:

    "Distribution specific packaging was severely broken for
    most distributions and has been dropped in the latest
    release."


This indicates that upstream has no interest in including or maintaining
distro-specific module packaging (and, indeed, mkrpm has been removed from
dkms too).

So, if upstream won't do it, perhaps debian's package of dkms should include
extra scripts providing the debian-specific functionality removed from dkms.

`dkms-mkbmdeb`, for example, could be a standalone wrapper script that uses
`dkms mktarball --binaries-only`. It could be based on the mkbmdeb code
removed from dkms.

ditto for `dkms-mkdeb` and `dkms-mkdsc` scripts.

Having separate scripts would also make it easier to keep dkms up-to-date with
upstream without having to patch it on every build.

craig

PS: not having to have the linux headers and a complete build environment on
every machine would be useful. My fastest machine, for example, can compile
the ZFS dkms module in a minute or so (per kernel version, and I typically
have at least two, current and previous on every machine) while my other
machines can easily take 15 or 20 minutes or more.

I'd like to also signal that I'm interested in keeping this
functionality around. I looked at the current dkms source and it's not
*that* complicatd. It's basically one (rather big, 100 lines) shell
function which does everything.

Also, it seems to me we should be able to get away with just
replicating mkdsc: once we have a source package, we can use our
normal tools to build the rest...

It looks like it's basically:

    invoke_command "cp -ar '$DEBDIR/' '$temp_dir_debian'" "copying template"
    invoke_command "cp -Lpr '$dkms_tree/$module/$module_version/source' '$temp_dir_debian/$module-$module_version'" "Copying source tree"
    invoke_command "dpkg-buildpackage -S -us -uc 1>/dev/null" "Building source package" || \

Now obviously, maybe those templates are gone too so we'd need to keep
that up to date, but it seems that's somewhat feasible...

Hi everyone,

Now it reached stable/bookworm ...

I just ran into it and are in desperate need for packaging (also zfs), do first
tried to manually reverse the changes referenced above, but there were too many
changes, so I started to manually craft the package on basis of a working bullseye
package.

This needs polishing, yet it "works for me", so maybe it is of some use for
anyone trying to package zfs modules.

-----------------------------------------------%<
#!/bin/bash

export LANG=C

DETECTED_VERSION=""

# be smart and try to detect if we have only one kernel
if [ "$( find /lib/modules/  -maxdepth 1 -mindepth 1 -type d | sed -e 's%/% %g' | awk '{print $NF }' | wc -l )" == "1" ]
then
    DETECTED_VERSION=$( find /lib/modules/  -maxdepth 1 -mindepth 1 -type d | sed -e 's%/% %g' | awk '{print $NF }' )
fi

KERNEL_VERSION=${1:-$DETECTED_VERSION}

if [ "$KERNEL_VERSION" == "" ]
then
    echo "ERROR: Please provide kernel version!"
    exit 1
fi

if [ ! -e "/usr/lib/modules/$KERNEL_VERSION/updates/dkms/zfs.ko" ]
then
    if [ -e "/usr/lib/modules/${KERNEL_VERSION}-amd64/updates/dkms/zfs.ko" ]
    then
        KERNEL_VERSION=${KERNEL_VERSION}-amd64
    else
        echo "ERROR: ZFS module for kernel $KERNEL_VERSION was not found, cannot continue!"
        echo ""
        find /usr/lib/modules/*/updates/* -type f
        exit 1
    fi
fi

ZFS_VERSION=$( modinfo /lib/modules/${KERNEL_VERSION}/updates/dkms/zfs.ko | grep ^version | awk '{ print $NF }' | cut -d- -f1 )

TMPDIR="/tmp/build.$KERNEL_VERSION"
rm -rf $TMPDIR
mkdir -p $TMPDIR/debian
cd $TMPDIR

mkdir -p src/lib/modules/$KERNEL_VERSION/updates/dkms
cp -R /usr/lib/modules/$KERNEL_VERSION/updates/dkms/*.ko src/lib/modules/$KERNEL_VERSION/updates/dkms

cat > debian/changelog <<EOF
zfs-modules-${KERNEL_VERSION} ($ZFS_VERSION) stable; urgency=low

  * ZFS ${ZFS_VERSION} modules for kernel ${KERNEL_VERSION}

Hello everyone,

In case anyone is interested in ZFS packages:

I created a bit hacky way to package ZFS binary modules for Debian 12
which uses dkms mktarball --binaries-only underneath.

If someone wants to take a look the package is on GitHub:
https://github.com/fihufil/debian-zfs-modules

It builds packages just fine but there is one gotcha: the packages are
unsigned so it won't work on systems with Secure Boot enabled.

KR,
Filip Dorosz

The dkms-mkbmdeb functionality no longer existing in Debian 12
upset my workflow, so I created an addon package to restore it:

https://github.com/uecasm/dkms-mkbmdeb

It should work with all existing packages and most existing
workflows with just minor tweaks.