From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLnuN-0002Vv-Gm for guix-patches@gnu.org; Sun, 11 Nov 2018 06:28:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLnuM-0003th-RR for guix-patches@gnu.org; Sun, 11 Nov 2018 06:28:03 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:41086) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLnuM-0003tO-MX for guix-patches@gnu.org; Sun, 11 Nov 2018 06:28:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gLnuM-0001GS-Hl for guix-patches@gnu.org; Sun, 11 Nov 2018 06:28:02 -0500 Subject: [bug#33329] [PATCH] gnu: Deprecate linux-module shpchp and tell user to remove it. Resent-Message-ID: From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87h8jbang2.fsf@elephly.net> <01fa8c80-c57c-f73a-cec1-af91cacb58bf@riseup.net> <290b28ec-cd1e-e5e8-275e-133771c7d4f3@riseup.net> <87lg60va39.fsf@gnu.org> <87muqglbak.fsf@posteo.net> Date: Sun, 11 Nov 2018 12:27:22 +0100 In-Reply-To: <87muqglbak.fsf@posteo.net> (Brett Gilio's message of "Sat, 10 Nov 2018 18:15:15 -0600") Message-ID: <87sh07ua5h.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Brett Gilio Cc: rekado@elephly.net, 33329@debbugs.gnu.org Brett Gilio skribis: > Ludovic Court=C3=A8s writes: > >> If anything, what should be improved IMO is the error message you get >> when specifying a module that is unavailable. That=E2=80=99s not easily= done >> though since that happens at build time. > > I think Ludo is correct in this, an error message seems to be the only > option we have to ensure that maintainability and reproducibility are > respected. To add onto that, I was thinking that maybe it could be part > of the configuration process that we could modify to ensure that all of > the specified modules that are needed are available else it throws an > error? That already happens, but the check cannot be 100% accurate because it relies on information from the currently running kernel, which is why there=E2=80=99s the =E2=80=98--skip-checks=E2=80=99 option. Ludo=E2=80=99.