
<!DOCTYPE html><html><head><title></title></head><body><div>On Tue, May 12, 2026, at 16:48, Ulrich Wexler wrote:</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div>But what I don't understand is why you guys don't mark the kernel as incompatible?</div></div></blockquote><div><br></div><div>TL;DR: kernels aren't numbered in a suitable way. On Debian for example, packages like linux-image-amd64 are versioned with the full kernel version - eg: 6.12.73-1, or 7.0.4-1~bpo13+1. Getting the conflicts or depends correct under all circumstances is nontrivial, as you can't wildcard them. (Yes, it's <b>possible</b> with hacks like "< 6.19.999", but one needs to consider the tradeoffs between this kind of dependency and the possibility of edge case breakage when something unexpected happens upstream.)</div><div><br></div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div>I'm actually thinking about writing a pre-install hook which intercepts `zfs-dkms`, unpacks the `control` and `/META`, adds the appropriate max kernel version, repacks and then installs that instead.</div></div></blockquote><div><br></div><div>An easier approach, for what it's worth, is what I do - instead of installing linux-image-amd64, I maintain a local package "zfs-linux-image-amd64" which strictly depends on specific kernel and zfs-dkms | zfs-modules versions. This is pulled in from my local repository, and ensures that no upgrades happen until I've validated that they work.</div><div><br></div><div>Colm</div><div><br></div><div id="sig155774055"><div class="signature"><span class="size" style="font-size:88.89%;"><span class="color" style="color:rgb(211, 211, 211);">-- </span></span><span class="color" style="color:rgb(211, 211, 211);"></span></div><div class="signature"><span class="size" style="font-size:88.89%;">Colm Buckley / colm@tuatha.org</span></div></div><div><br></div></body></html>