Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master
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
Reply to: