[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master



On Thu, Mar 01, 2018 at 10:48:57PM -0500, Antonio Russo wrote:
> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-devel@lists.debian.org
> 
> --- Please fill out the fields below. ---
> 
>    Package name: zfs-linux-git
>         Version: 0.8~
> Upstream Author: Brian Behlendorf <behlendorf1@llnl.gov>
>             URL: http://www.zfsonlinux.org/
>         License: CDDL
>     Description:
>  ZFS is an advanced file system and volume manager which was originally
>  developed for Solaris. It provides a number of advanced features like
>  snapshots, clones, live integrity checksums, deduplication, compression,
>  encryption, and much more. The port to the Linux kernel includes a
>  functional and stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL).
>  .
>  This package is a very close fork of the existing zfs-linux package
>  already in Debian, but aims to track git master and the ntrim2-next
>  patch set adding trim support by Tim Chase.
>  .
>  BEWARE: THIS VERSION OF ZFS IS EXPERIMENTAL. IT MAY EAT YOUR DATA.
> 
> 
> Just like the parallel packaging of wine-unstable and wine, I have
> packaged [1] a -git version of zfs (and spl). Actually, the version is
> a rebase of a PR [2] by Tim Chase [3] to add trim/unmap support to ZFS.
> This appears to be getting close to a mainline inclusion, and there has
> gathered much interest. The git mainline already includes encrypted
> datasets.
> 
> I am proposing adding this package to the experimental repository (as
> it definitely does not meet the quality and stability requirements for
> any Debian release). The exposure of these experimental features to
> the broader Debian community provides a better test-bed for the
> zfsonlinux mainline (and for this ntrim2-next PR especially). This
> testing improves the quality of the released version, protecting
> Debian users not as willing to test out the newest features
> filesystems.
> 
> Moreover, because the packaging is---and will remain, to the best of my
> ability---close to the released-version ZFS packaging, changes
> migrating into the release version from master that require adaptations
> to the Debian packaging will have already been addressed (by myself).
> This should alleviate some of the demands on the already overburdened
> maintainers of zfs-linux.

(CC-ing the existing ZoL Debian packaging team, although there is hardly
ever any response there..)

as an upstream contributor and with my downstream/derivative hat on I
have an alternative proposal:

I've been pondering cleaning up and pushing the existing Debian
packaging (or some variant thereof) upstream to replace the ugly "build
rpms and use alien + various hacks to get some sort of .deb output"
"build system" that is currently used.

it seems like upstream is just lacking the people and knowledge to do
this, but it would be welcome (see config/deb.am). would you be
interested in teaming up on this?

there are quite a lot of people running git master or the latest 0.7.x
release on some variant of Debian/Ubuntu that get tripped up on every
other release because of missing files and lack of integration into
Debian tooling, probably more than would be willing/able to track
experimental ;)

this would also have the big upside of being able to integrate the
upstream Debian packaging directly into zfs-buildbot infrastructure,
hopefully keeping most of the packaging-related issues we've seen in the
past from being part of any tagged releases in the future.

the only real downside I see is the fact the the debian/ folder would
need to be excluded when importing stable upstream releases into Debian
proper, in favor of cherry-picking the relevant packaging changes only
as separate commits afterwards (but this is easy with the existing GBP
workflow, and something that a lot of packages with upstream debian/
folders handle just fine).


Reply to: