On 6/22/18 4:17 AM, Fabian Grünbichler wrote: > > 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.
dh_missing was added in debhelper 10.3. I'll remove the use, and suffer the deprecation warning. > - 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 It would be a real pity if we had to keep these packages separated. Everything is much easier to maintain and build in a single package. Moreover, actually separating the now-merged upstream packaging is going to be a challenge---and probably will introduce weird bugs. If, for some reason, this must be separated, I think we should consider automatically building these binaries on the user's machine, like say libdvd-pkg, before we consider splitting splitting the packaging: It would be unacceptable to allow a bug in a filesystem driver to be introduced to work around a licensing issue. I'll formulate the question carefully, and submit it to debian-legal. I will say that the CDDL specifically allows for inclusion in a "Larger Work", and similarly, GPL says that "mere aggregation" is insufficient to have the license apply to the rest of it. What *will* be important is making sure that each source file license is properly tracked in copyright---so as to ensure each distributed non-source file be subject to at most one of the two licenses. As for the section: I imagine it would stay in contrib---for the same reasons it was originally placed there. > - which distros do we want to support upstream? Debian Stretch+, Ubuntu > Xenial/Bionic/Cosmic? just the latest ones? I only have experience with Debian. The Ubuntu packaging looks very different---in particular, they look like they build the module with the kernel (https://wiki.ubuntu.com/ZFS). I don't see any reason to try to support that. > - compat 10 or 11? Stretch only has 10 without backports.. I say we target 10. > > 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) Changed. > - 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? It's in override_dh_dkms, and clean it up there too. > - 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? Cleaned up as suggested. Might as well, since you've noticed it. > - 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? This sounds reasonable. I was only ever targeting this script at upstream git snapshots. My use case is a script that just checks out and builds the next git version, making it available for use. > - 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?) > git-shortlog should be able to do this relatively easily. I'll get around to these last two points eventually. > I'll do some test builds and check the resulting packages later on - > thanks for getting the ball rolling! > Thanks for looking at this! Antonio
