On May 17, 2015, at 1:25 PM, Cyril Brulebois wrote:
> Aron Xu <aron@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.
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail