Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master
(trimmed down a bit)
On Fri, Jun 22, 2018 at 06:49:48PM -0400, Antonio Russo wrote:
> On 6/22/18 4:17 AM, Fabian Grünbichler wrote:
> > - 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.
I guess there is a sane argument for merging the source and binary
packages since upstream does the same. We have to ensure proper
transitioning though, especially for spl-dkms to zfs-dkms, both inside
Debian, and for users switching to the snapshot packages built from
upstream git. If debian-legal/ftp-masters don't object, I am all for it
:)
> > - 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.
This was more meant for upstream inclusion - the more and older distros
we want to support, the more attention we need to pay to tooling
compatibility. I'm sure there are a lot of Ubuntu users that would like
to use upstream snapshot and "most current release" packages. Whether
the Ubuntu maintainers want to re-use parts of the then upstream
packaging or not is of course up to them.
That Ubuntu ships the modules pre-compiled with their kernel is not an
issue - zfs-dkms would contain a newer version, and thus be used. Maybe
it makes sense to offer two build profiles for DKMS and kmod style
binary modules? There is some support for this in d/rules, but I haven't
tried the -modules stuff yet. Ubuntu is not the only downstream that
does not build ZFS DKMS packages, but ships pre-built modules, and
individual users might also want to build the modules once and deploy on
many hosts. I know DKMS supports this as well nowadays, but skipping
that extra step would still be nice..
> > - 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.
Starting with 0.8, it would be nice to also build official upstream
release packages with proper Debian packaging. In that spirit, I am all
for supporting both "build from release tag" and "build from arbitrary
commit".
Reply to: