On Wed, Jun 06, 2018 at 12:17:13AM -0400, Antonio Russo wrote: > I have packaging of zfsonlinux (for upstream git revisions) that > is in need of review [1]. It builds, and zfs-dkms builds as well. > I have only done very superficial testing (i.e., the zfs module > loads, you can create a pool). > > This was somewhat nontrivial because upstream recently merged spl, > the "Solaris Porting Layer", into zfsonlinux. In the short term, > this made packaging more challenging, but in the long term it will > make maintenance much easier. > > Highlights from this new packaging: > > 1. Upstream now ships explicit an statement of kernel version > compatibility [2]. I've integrated that into the debian packaging, > so the maintainer will no longer have to update that manually. > > 2. Tunable parameter to put architecture independent zfs scripts > in a Debian FHS compliant location [3]. Hopefully, future > additions of scripts will use this parameter and Debian will get > that compliance "for free". I expect this to be merged relatively > soon, further simplifying the packaging. > > 3. debian/update-git , which automatically builds a changelog > for an upstream git revision. Another tool to simplify an > ambitious user's desire to build a recent git version. > > I'd appreciate feedback.
as promised, and unfortunately delayed a bit longer than I wanted. thanks for the initial push - some of the points are more for a discussion with upstream regarding their inclusion of some variant of this, some are for debian experimental. - compat 12 is IMHO too new for anything except experimental, it's still subject to change. - given the different licences and thus parts of the archive, I am not sure whether we can merge zfs-dkms and spl-dkms inside Debian - which distros do we want to support upstream? Debian Stretch+, Ubuntu Xenial/Bionic/Cosmic? just the latest ones? - compat 10 or 11? Stretch only has 10 without backports.. debian/rules: - chmod a-x files should be on separate lines, otherwise git blame is stupid ;) - same for copied/installed scripts that need to be listed explicitly (DKMS) - the dmks.mkconf call does not belong into dh_auto_install (semantically). does it need to be there or can we move it to dh_auto_configure or dh_auto_build ? why not keep it in override_dh_dkms? - same for the "make dist" call, which should probably be run before the build to prevent mistakes in "make dist" from tainting DKMS sources with build products? - debian/git-version.sh could benefit from some comments/rationale ;) - debian/git-version.sh does not handle actual release tags correctly (the resulting package version is a native one) - debian/git-version.sh should probably somehow handle adding a pkgrelease suffix as well? maybe as optional, second parameter (defaulting to 1), and in case it is ommitted but d/changelog contains the same version with -1, bump it to -2? - debian/update-git: it would be cool to pre-populate the changelog with a shortlog since the previous version (if the previous version matches either the git-describe or release tag versioning scheme, alternatively we could just encode the git commit in the changelog like "gbp dch --snapshot" does?) I'll do some test builds and check the resulting packages later on - thanks for getting the ball rolling!