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
>
