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