From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39393) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gLkB8-00053u-Uw for guix-patches@gnu.org; Sun, 11 Nov 2018 02:29:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gLkB4-0001s0-Va for guix-patches@gnu.org; Sun, 11 Nov 2018 02:29:06 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:40995) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gLkB4-0001r8-RO for guix-patches@gnu.org; Sun, 11 Nov 2018 02:29:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gLkB4-0003kG-H8 for guix-patches@gnu.org; Sun, 11 Nov 2018 02:29:02 -0500 Subject: [bug#33329] [PATCH] gnu: Deprecate linux-module shpchp and tell user to remove it. Resent-Message-ID: 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> From: swedebugia Message-ID: Date: Sun, 11 Nov 2018 08:27:59 +0100 MIME-Version: 1.0 In-Reply-To: <87muqglbak.fsf@posteo.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 , Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: rekado@elephly.net, 33329@debbugs.gnu.org On 2018-11-11 01:15, Brett Gilio wrote: > > Ludovic Courtès writes: > >> If anything, what should be improved IMO is the error message you get >> when specifying a module that is unavailable. That’s 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? Ok. Would my patch have worked anyway? So where would that error message be produced? In gnu/build/linux-modules? load-linux-modules? -- Cheers Swedebugia