[Pkg-zfsonlinux-devel] any news/reply regarding ZFS in NEW?

[Turbo Fredriksson]

On Mar 2, 2014, at 4:52 AM, Dimitri John Ledkov wrote:

> Hostile binary takeover is not allowed - that is two separate source
> packages should not build the same binary package names, even if on
> different architectures.

Ok, sounds reasonable when you say it like that. I'd still appreciate a link to the policy for that.

I think (explanation below) that in this case, it would/could be warranted to keep the names and do
the "hostile binary takeover" as you put it.

> Since these are two different implementations

> why existing zfsutils packages just can't enable compilation on "linux-any"?!

You said it yourself - they are different implementations. Yes, they share a lot (!!) of similar
code, but they are also not compilable on their "opposite" arch. 

That is what OpenZFS.org is for - eventually (hopefully sooner than later), you/we/I will be able to
do just that - one source base for all architectures (Linux, FreeBSD, Illumos etc). But we (they) 
aren't there yet.


As it stands today, there are two "upstream sources" for/in Debian GNU/Linux - one for the Linux
kernel and one for the FreeBSD kernel. These share _a lot_ (I can't give you an exact figure, but if
I had to give a "between thumb and index finger guess", I'd say 90%) of the same code (they both
originated from the last open Solaris release before Oracle closed the source again) and provide the
exact same functionality, in the exact same way with binary programs that behave the exact same way
(same options and parameters etc).

> The conflict is there, by virtue of enabling multiarch one can install
> "zfsutils" for either a linux or kfreebsd architecture

Are you saying that with multiarch, it's possible to install packages for two completely different
kernels - Linux and FreeBSD!?


> Changes to partman-zfs on linux-any, confuse and surprise me, as that
> implies providing a pre-build dmks module for the installer's Linux
> kernel which is not redistributable.

That was not (and I still haven't seen a categorical proof of this!) determined at the time.


Besides, even if this is eventually proved and decided, having the support for ZFS in d-i/partman
for linux would still be a good option. People can have their module loaded manually or manually put it on their own, private CD/DVD or FTP repo etc.

> DId partman-zfs/linux-any relied on compiling -dkms module?

Yes and no.

The module will off course be required to "enable" the functionality at the time of booting the
installation - I wrote it in such a way that if there is no ZoL support, that part of d-i/partman
will be disabled.

Installing on a ZFS filesystem on Linux will just not be available/possible/shown if the ZoL module
isn't available. It doesn't require any linking with any ZoL library etc when creating the
boot/install "stuff", so in that regard, there is no licensing issue by accepting the patches.

The changes [to d-i/partman] was quite minor, so not accepting them just because there is/might be a
licensing issue with distributing a binary module in/with Debian GNU/Linux might be a little
nitpicking.
-- 
I love deadlines. I love the whooshing noise they
make as they go by.
- Douglas Adams