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 -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1653c1e1-c18e-47b1-b162-7120e001f...@bayour.com
