make native-deb should be removed, since it's never worked in a 2.2 release tarball

[rincebrain]

Attempting to make native-deb or any of the children of it, including make native-deb-utils, will not work in any released tarball, because the tarballs are prepared incorrectly and missing most of contrib/debian/.

They will error out with

config.status: creating contrib/debian/rules
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating lib/libzfs/libzfs.pc
config.status: creating lib/libzfs_core/libzfs_core.pc
config.status: creating lib/libzfsbootenv/libzfsbootenv.pc
config.status: creating module/Kbuild
config.status: creating module/Makefile
config.status: creating rpm/generic/zfs-dkms.spec
config.status: creating rpm/generic/zfs-kmod.spec
config.status: creating rpm/generic/zfs.spec
config.status: creating rpm/redhat/zfs-dkms.spec
config.status: creating rpm/redhat/zfs-kmod.spec
config.status: creating rpm/redhat/zfs.spec
config.status: creating tests/zfs-tests/tests/Makefile
config.status: creating zfs.release
config.status: creating zfs_config.h
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing po-directories commands
cp -r contrib/debian debian; chmod +x debian/rules;
cp contrib/debian/control debian/control; \
dpkg-buildpackage -b -rfakeroot -us -uc;
cp: cannot stat 'contrib/debian/control': No such file or directory
dpkg-buildpackage: error: cannot open file debian/changelog: No such file or directory
make: *** [Makefile:14290: native-deb-utils] Error 255

On any of 2.2.0 through 2.2.6.

[Gendra13]

Wouldn't it make more sense to fix the tarball instead of removing the option?
Because if you just do a git clone from master or the 2.2-release branch instead of using the tarballs, make native-deb-utils is working perfecly.

[rincebrain]

You would think so.

But since it's been broken for a year, and it's been reported several times to the people generating releases without any change, I've given up on that happening.

[wmmur]

@rincebrain interesting? do you want to destroy something that works (make native-deb-utils) and leave make deb that doesn't work? #16478

[rincebrain]

I'd rather we stopped claiming that building packages worked if we don't test it and don't fix it when it's broken.

I'm tired of having to explain to people for a year that it's known to be broken.

Honestly, I'd remove the alien'd deb target while we're at it, because those would require a lot of patches to alien to be able to actually work reliably.

[wmmur]

@rincebrain I use make native-deb-utils compilation. tested for >=zfs-2.2.4, make deb does not work. I'm sorry you've had such a negative experience.

[rincebrain]

You should probably read the report before commenting any more.

The entire point is that the release tarballs do not work, for any version. I tried this on all of the release tarballs from 2.2.0 to 2.2.6. They do not contain most of the files needed for this to ever work, on any release, ever.

This has been reported, and not fixed, just like "make -j native-deb" has been broken since it was merged, and not fixed, other than saying "don't do that".

If we're not going to fix it, we should stop pretending to support it.

[robn]

All other things being equal, I agree that nothing is better than a broken thing. However, the fact that there is a broken thing is at least a statement of intent, so if its still wanted and not hard to fix, then I'm more on the side of fixing it, as long as that happens.

It sounds like its more of a symptom, than a cause, and that's more about tarballs being broken. I've seen that myself on the FreeBSD side (in a customer project where git wasn't readily available); that one was easily fixed though.

@tonyhutter with your release manager hat on, how "working" do you expect the tarballs to be? Would you prefer that broken options like this are fixed for all cases, removed for all cases, or gated off to tarball builds? Or something else?

[nabijaczleweli]

Given opinion from 2023-04 and opinion on original PR from 2022-05, shall I say... vindicated?

[nabijaczleweli]

Someone should probably do a more thorough review of the tracker but #15638 and #16289 indicate, to me, that the package also doesn't work from a checkout.

(Also this is a dupe of #15404.)

[rnickle]

Someone should probably do a more thorough review of the tracker but #15638 and #16289 indicate, to me, that the package also doesn't work from a checkout.

(Also this is a dupe of #15404.)

I agree that there are issues with building from a tar-ball, but I have been successful in building native-deb, native-deb-kmod and native-deb-utils from a checkout on Ubuntu 24.04 and Debian 12.

[nabijaczleweli]

just building, or actually using? #15638 at least certainly indicates to me that it builds, but "actually using" it doesn't really happen

let's see what the original PR says should happen here:

Proper Debian style packaging can:

1. Make things easier for developers to have an actively managed packaging for Debian based systems.
2. Ease the testing and development of ZFS packages on Debian based systems.
3. It may also serve as a starting point for downstream projects to base their packaging on and add their own customization.
4. Current .deb packages do not include debug symbols and information to facilitate debugging process.

1 seems farcical, 2 has certainly not come to pass (and is nonsensical on its face, to me), 3 is weird given that there's no reason to... use this packaging? instead of the one from debian? if you're building debian (debian derivative) packages?, 4 is an outright lie for real Debian packages, and just fix the alien ones if they don't have dbgsyms? lol

the original goals seem, to me, clearly unmet, this has increased support load, it doesn't work at all in any released version, and barely? works? or is subtly broken? on trunk

[nabijaczleweli]

If you don't consider "support load increased" self-evident, a cursory glance says #14736 #15404 #15586 #15638 #16289 are all "contrib/debian is broken" AFAICT.

[rnickle]

If you don't consider "support load increased" self-evident, a cursory glance says #14736 #15404 #15586 #15638 #16289 are all "contrib/debian is broken" AFAICT.

Thanks for summarizing the issues.

[behlendorf]

Thanks for fully cataloging the issues and opening a PR to get feedback. I agree, this hasn't exactly been as trouble free as I was originally hoping. However, before we go ahead and remove this functionality we should do an honest assessment of what it will take to fix the open issues and properly maintain it. @usaleem-ix can you investigate the open issues.

[nabijaczleweli]

(ftr this is just what i got from searching "native deb" and "contrib/debian" and a cursory ^F inside, so i don't expect this to actually be exhaustive)

[m-ueberall]

I agree that there are issues with building from a tar-ball, but I have been successful in building native-deb, native-deb-kmod and native-deb-utils from a checkout on Ubuntu 24.04 and Debian 12.

just building, or actually using? #15638 at least certainly indicates to me that it builds, but "actually using" it doesn't really happen

FWIW, I switched to make native-deb a while ago on Ubuntu 20.04/22.04 (arm64/amd64, 2<n<10 machines) and everything works as expected – including the automatic dkms-based rebuilds after a kernel upgrade – once you reboot from a rescue image once and thoroughly replace all zfs* packages by their openzfs-* "counterparts".

[usaleem-ix]

@usaleem-ix can you investigate the open issues.

I am working on that.

[wmmur]

I use make native-deb on Devuan Ceres and Debian Sid. compilation works, installation of openzfs-* packages, including dkms compilation of kernel modules.
Edit
However, I understand that it is "support load increased".

[behlendorf]

I'd prefer to try and work through the reported issues before we consider dropping this support. A first round of fixes was merged in #16604 which we'll back port for 2.2.7.