From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id GJPtOak85V8nQAAA0tVLHw (envelope-from ) for ; Fri, 25 Dec 2020 01:13:13 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id CEejNak85V+RLwAAbx9fmQ (envelope-from ) for ; Fri, 25 Dec 2020 01:13:13 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 41A3A940142 for ; Fri, 25 Dec 2020 01:13:13 +0000 (UTC) Received: from localhost ([::1]:39346 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ksbfL-00065c-VZ for larch@yhetil.org; Thu, 24 Dec 2020 20:13:11 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54960) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ksbfC-00065E-5q for guix-patches@gnu.org; Thu, 24 Dec 2020 20:13:05 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:44791) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ksbfB-0005Cj-To for guix-patches@gnu.org; Thu, 24 Dec 2020 20:13:01 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ksbfB-0006Ti-No for guix-patches@gnu.org; Thu, 24 Dec 2020 20:13:01 -0500 X-Loop: help-debbugs@gnu.org Subject: [bug#45403] [PATCH] gnu: zfs: Split into packages specific for each of our major supported kernel versions. References: In-Reply-To: Resent-From: raid5atemyhomework Original-Sender: "Debbugs-submit" Resent-CC: guix-patches@gnu.org Resent-Date: Fri, 25 Dec 2020 01:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 45403 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: "45403@debbugs.gnu.org" <45403@debbugs.gnu.org> Received: via spool by 45403-submit@debbugs.gnu.org id=B45403.160885874924863 (code B ref 45403); Fri, 25 Dec 2020 01:13:01 +0000 Received: (at 45403) by debbugs.gnu.org; 25 Dec 2020 01:12:29 +0000 Received: from localhost ([127.0.0.1]:56337 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksbee-0006Sw-UU for submit@debbugs.gnu.org; Thu, 24 Dec 2020 20:12:29 -0500 Received: from mail-40137.protonmail.ch ([185.70.40.137]:39960) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ksbec-0006Sg-0P for 45403@debbugs.gnu.org; Thu, 24 Dec 2020 20:12:27 -0500 Date: Fri, 25 Dec 2020 01:12:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1608858739; bh=u9gwkZnS6JZzIwKXGM4/M1fQk5uw+qVlX4WUROqZIaM=; h=Date:To:From:Reply-To:Subject:From; b=avSVNDvomakQPOC6qNV1T9d/c7nclPcYQXWQ9NqfyU1ZQlAKkajxaiGt1HztHMgTl xnxWwjdoBwpisvnI+aNYWMWF6oXizVtyX0fYMhPNT/0DZhaYBmbV4UNmS2nL5asQFg wT/TQYd7ZTnUkH9FioeICnDGBQEoVztos6jV3lPo= Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+larch=yhetil.org@gnu.org Sender: "Guix-patches" Reply-to: raid5atemyhomework , raid5atemyhomework via Guix-patches From: raid5atemyhomework via Guix-patches via X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.82 Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=protonmail.com header.s=protonmail header.b=avSVNDvo; dmarc=pass (policy=none) header.from=gnu.org; spf=pass (aspmx1.migadu.com: domain of guix-patches-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-patches-bounces@gnu.org X-Migadu-Queue-Id: 41A3A940142 X-Spam-Score: -2.82 X-Migadu-Scanner: scn1.migadu.com X-TUID: qiaYNoLhsI3N > There are primarily two ways to use Guix with a local Git repo. > > First, you can follow the instructions in the manual section Contributing= , specifically the sections Building from Git and RunningGuix Before It Is = Installed. > > Or, you can use something like `guix pull --url=3D/path/to/my/repo --comm= it=3Dmycommit`. Thank you very much, will check. > Beyond that, does this patch create linux-libre packages with ZFS support= compiled in? No, this patch continues to use the existing technique of downloading ZFS a= s source and compiling it as a kernel module you have to load in, as per li= censing incompatibility. What it changes is that it compiles kernel modules for all guix-provided ke= rnel versions that ZFS currently is rated to support, rather than compile a= kernel module for whatever `(default-linux)` is, which is always the lates= t and greatest kernel (currently 5.10) which ZFS is currently not rated for= . As Guix goes through the trouble of maintaining a `linux-libre-4.4` package= I assume at least one user somewhere is using Linux 4.4, and did not want = to prevent that user from using ZFS if they decide to do so someday. I admit the naming scheme `linux-5.9-zfs` does make it seem like the packag= e contains an entire Linux kernel. The alternative is to call it `zfs-for-linux-5.9` but that makes the entire= package name with version `zfs-for-linux-5.9-0.8.5` which I think is worse= , because the version numbers are right next to each other. What naming scheme would you suggest? * `linux-5.9-zfs` --- makes it look like it contains a whole Linux kernel. * `zfs-for-linux-5.9` --- versions are right next to each other: `zfs-for-l= inux-5.9-0.8.5`, this is bad since some versioning conventions include a `-= ` in the version naming, so at a glance this makes for a very confusing ver= sion. * `kernelmodule-5.9-zfs` --- makes it clear that it is not an entire kernel= , but this package *also* includes userspace utilities not just the kernel = module. * `zfs-for-linux-5.9-version` --- kind of a weird and absurdly lengthy name= but maybe palatable? I imagine a similar problem would occur for other kernel modules --- the in= ternal kernel interfaces are *not* stable at all, so complex external kerne= l modules like ZFS need to know what kernel version it's being compiled for= and include a bunch of `#ifdef`s to compensate. So we need some decent convention for "how do we name kernel modules so tha= t they are targeted for each kernel version".