On May 17, 2015, at 1:25 PM, Cyril Brulebois wrote: > Aron Xu <a...@debian.org> (2015-05-17): >> At the moment only spl is available in the archive, using dkms, and >> for zfs it's similar in the way of packaging though not uploaded yet. >> What we have (code ready to go) is a mechanism that detects/gets >> definition of a current KVERS and generate a source package with >> dependencies and binary packages with names corresponding to it. > > My personal stance on kernel related things would be “upstream first”.
I'm not exactly sure what you mean by that, but if you mean that upstream (i.e. ZFS On Linux - "ZoL" in this case) should have the support to build binary modules package(s), then they do. BUT, it's somewhat of a hack. The debs upstream build is from alien the rpm which it natively have. And if we're talking about udebs, there is no need for that in upstream. If we're talking about upstream as the Linux kernel sources, because of the CDDL license of ZoL, we're _NEVER_ (ever, ever!!) going to be able to put it in the Linux kernel source tree. Unless someone that's never seen the ZoL code decides to … reverse engineer one of the most advanced filesystems ever created (so far). "I doubt" (do get I a "understatement of the year" award for that?? :) that will ever happen either. > If it ain't going to be merged into mainline, or at least accepted as a > patchset (like e.g. aufs3 or rt in wheezy) for src:linux, I'm not sure > we want to support that. Currently (just to catch everyone up for those that haven't been paying attention :), I've been doing debs, udebs etc for both SPL (Solaris Porting Layer) and ZFS for ZoL "for years". I have also made a modified version of D-I (previous patches have been sent to relevant parties of Debian GNU/Linux although I've been, over the year, improving on them) that I supply to the ZoL community. But since Debian GNU/Linux was in "release mode", only a few of them was accepted. So when the packages are built, it also build the udebs for the kernel it's running on. Because we need ZoL support in the installer, with its limited space requirements, we can't obviously (!!) ship a build environment there as well to build the spl and zfs modules (from the existing dkms packages). We need the udebs. _Inside_ the installed system which is created, the dkms packages are used as normal. It's only in the "partition" phase of the install we need udebs. Building this for the current running system is, I agree, somewhat of a pain. BUT, since the kernel doesn't really change that much/often, I think _we_ (the pkg-zfsonlinux-devel) can handle it, to make sure that there's udebs for the kernel D-I is using. PS1. Because I personally _hate_, _loath_, _really don't like_ dkms, I created the option to create a {spl,zfs}-modules-source, much like I'm used to from the OpenAFS code (and others). But it still needs a build environment (just not necessarily on the host using ZoL - which I prefer not to have). PS2. Because I got the impression that binary modules wouldn't be allowed (still haven't heard anything definitive about that from the DPL etc), I started experimenting with using zfs-fuse for the installer part, and real ZoL modules (from dkms) for the 'finished product'. After a couple of weeks, I had a proof-of-concept that seemed to work. BUT, it's "The hack of all hacks" in my opinion, and I just can't recommend that course with a straight face. We need the udebs to get this "all the way" (to allow users to install a fully enabled ZFS system). -- Choose a job you love, and you will never have to work a day in your life.
signature.asc
Description: Message signed with OpenPGP using GPGMail