It boils down to the fact that you cannot have two packages on a system
that own, say, /lib/foobar.so.1 -- which is what you get if you want to
provide external drivers for multiple kernels.
On Thu, Nov 24, 2016 at 11:58 PM, Francesco Ferretti <skullbo...@sabayon.org
> wrote:
> But here the point is that even upstream in portage zfs is split in two
> packages and the difference between our zfs-kmod and the Gentoo one is only
> that we install zfs-kmod and spl using the same ebuild. So could this
> create any mess in our chroot?
>
> And about nvidia, why using the upstream version without split could lead
> us to a maintenance mess? I'm really curious about this because I cant
> understand well why that split is there.
>
> On Thu, Nov 24, 2016 at 10:53 PM Fabio Erculiani <
> fabio.erculi...@gmail.com> wrote:
>
>> The problem is not really between zfs-kmod and spl, but between zfs and
>> zfs-kmod. zfs in fact is also shipping userspace tools, and you cannot
>> really make it work across multiple kernels without separating the
>> userspace part (zfs in our case) from the kernel module part (zfs-kmod). In
>> our build chroot we support several kernels at the same time, so merging
>> the two packages together is just going to create a wonderful maintenance
>> mess. This is the same reason why we have nvidia-drivers and
>> nvidia-userspace.
>>
>> Furthermore, having these separate packages allows us to support, even on
>> the user systems' side, multiple kernels at the same time, thus a smoother
>> upgrade path from an older kernel to the new one, because you can have the
>> pkg installed for the old and new kernel.
>>
>> Remember that there is usually a reason why certain decisions were made
>> in the past, but you need to ask or dig a little bit here and there.
>>
>> On Thu, Nov 24, 2016 at 3:02 PM, Francesco Ferretti <
>> skullbo...@sabayon.org> wrote:
>>
>> Ok I bumped our zfs-kmod fork to the last version available on portage
>> and injected it for every kernel versions we ship, let me know if all works
>> for you.
>> However I agree with Ben about the fact that if you are using zfs, you're
>> enough expert to manage the zfs, zfs-kmod, spl package version
>> consistency.
>>
>> About versions of zfs, I currently compiled the gentoo version of the
>> ebuild since practically don't have difference between our version and the
>> upstream one as you can see from the following diff:
>> --- /var/lib/layman/sabayon/sys-fs/zfs/zfs-0.6.5.6.ebuild 2016-05-05
>> 19:50:38.300440904 +0200
>> +++ /usr/portage/sys-fs/zfs/zfs-0.6.5.6.ebuild 2016-11-06
>> 05:00:39.000000000 +0100
>> @@ -3,7 +3,7 @@
>> # $Id$
>>
>> EAPI="5"
>> -PYTHON_COMPAT=( python{2_7,3_3,3_4,3_5} )
>> +PYTHON_COMPAT=( python{2_7,3_4,3_5} )
>>
>> if [ ${PV} == "9999" ] ; then
>> inherit git-r3 linux-mod
>> @@ -11,7 +11,7 @@ if [ ${PV} == "9999" ] ; then
>> EGIT_REPO_URI="git://github.com/zfsonlinux/${PN}.git
>> <http://github.com/zfsonlinux/$%7BPN%7D.git>"
>> else
>> SRC_URI="https://github.com/zfsonlinux/${PN}/releases/
>> download/${P}/${P}.tar.gz"
>> - KEYWORDS="~amd64"
>> + KEYWORDS=" ~amd64"
>> fi
>>
>> inherit autotools-utils bash-completion-r1 flag-o-matic linux-info
>> python-r1 systemd toolchain-funcs udev
>>
>> If it's ok I will drop at least this atom from our for-gentoo overlay.
>>
>> On Fri, Nov 18, 2016 at 11:16 AM Ben Roberts <opti...@sabayonlinux.org>
>> wrote:
>>
>> We had a conversation about this in IRC the other week. 0.6.5.8 is in the
>> portage tree but not yet marked as stable. There's also maintenance
>> overhead because the sabayon ebuild is forked and merges the gentoo spl
>> package into the zfs binary package. I don't know who currently maintains
>> this.
>>
>> I think the reason for the split was to make it easier to install, but
>> IMHO anyone using zfs is probably tech savvy enough to manage the zfs,
>> zfs-kmod, spl package version consistency, so to get faster updates we
>> should could drop the split and take upstreams ebuilds as-is, if possible.
>>
>> I'm also using zfs extensively and my file server is stuck running 4.4
>> LTS as a result, so I too would like to see faster updates.
>>
>> Whether or not to ship upstream unstable zfs versions is another matter.
>> If we are to use upstream ebuilds, we can try adding the newest versions to
>> the SCR.
>>
>> On 18 Nov 2016 9:41 am, "Fabio Erculiani" <fabio.erculi...@gmail.com>
>> wrote:
>> >
>> > Too late, I'd like to see same-day patch releases.
>> >
>> > On Fri, Nov 18, 2016 at 10:37 AM, Geaaru <gea...@gmail.com> wrote:
>> >>
>> >> Yes, I agree. But I think that will be always a delay between zfs and
>> kernel until zfs will be integrate inside vanilla kernel if this will be
>> possible.
>> >>
>> >> I see now that v.0.6.5.8 support kernel 4.8.
>> >>
>> >> Thanks
>> >> G.
>> >>
>> >> On Fri, 2016-11-18 at 10:26 +0100, Fabio Erculiani wrote:
>> >>>
>> >>> I would rather like to see the ZFS On Linux people keeping up with
>> kernel releases.
>> >>>
>> >>> On Fri, Nov 18, 2016 at 10:19 AM, Geaaru <gea...@gmail.com> wrote:
>> >>>>
>> >>>> Hi guys,
>> >>>>
>> >>>> I just used last sabayon ISO image (Gnome) to recover a server but I
>> >>>> see that use kernel-4.8 where currently doesn't support ZFS.
>> >>>>
>> >>>> So, could be possible create ISO image with last kernel (4.8) and a
>> >>>> kernel with ZFS support (like 4.4.x)? From boot menu I can then
>> select
>> >>>> eventually a kernel with ZFS support.
>> >>>>
>> >>>> Is ISO image it is used for recover disaster or broken filesystem
>> could
>> >>>> be helpful have ZFS support inside ISO image?
>> >>>>
>> >>>> WDYT ?
>> >>>>
>> >>>> Thanks in advance for any comments.
>> >>>>
>> >>>> Bye
>> >>>> G.
>> >>>>
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Fabio Erculiani
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Fabio Erculiani
>> >
>> >
>> >
>>
>>
>>
>>
>>
>>
>>
>> --
>> Fabio Erculiani
>>
>
>
>
>
--
Fabio Erculiani
