From mboxrd@z Thu Jan  1 00:00:00 1970
From: ison <ison@airmail.cc>
Subject: Re: [BLOG] custom kernel config
Date: Fri, 17 May 2019 20:04:03 -0600
Message-ID: <20190518020358.6cvhdpoxuib5c7bh@cf0>
References: <20190401180434.GF21029@macbook41>
	<20190515180945.GA7636@macbook41> <87h89uo4kb.fsf@devup.no>
	<87d0kiaqc0.fsf@netris.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Return-path: <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
Received: from eggs.gnu.org ([209.51.188.92]:42718)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <ison@airmail.cc>) id 1hRomb-0006l8-Vo
	for guix-devel@gnu.org; Fri, 17 May 2019 22:09:10 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <ison@airmail.cc>) id 1hRohq-0000xv-Nl
	for guix-devel@gnu.org; Fri, 17 May 2019 22:04:15 -0400
Received: from mx1.cock.li ([185.10.68.5]:50565 helo=cock.li)
	by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
	(Exim 4.71) (envelope-from <ison@airmail.cc>) id 1hRohq-0000qZ-5b
	for guix-devel@gnu.org; Fri, 17 May 2019 22:04:14 -0400
Content-Disposition: inline
In-Reply-To: <87d0kiaqc0.fsf@netris.org>
List-Id: "Development of GNU Guix and the GNU System distribution."
	<guix-devel.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/guix-devel/>
List-Post: <mailto:guix-devel@gnu.org>
List-Help: <mailto:guix-devel-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-devel>,
	<mailto:guix-devel-request@gnu.org?subject=subscribe>
Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org
Sender: "Guix-devel" <guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org

On Thu, May 16, 2019, Mark H Weaver wrote:
> Marius Bakke <mbakke@fastmail.com> writes:
> 
> > I just want to point out an (IMO) easier way to provide a custom kernel
> > configuration, that does not involve the "make-linux-libre" procedure:
> >
> > (define-public linux-libre/custom
> >   (package
> >     (inherit linux-libre)
> >     (native-inputs
> >      `(("kconfig" ,(local-file "kernel.config"))
> >        ,@(alist-delete "kconfig"
> >                        (package-native-inputs linux-libre))))))
> >
> > At the end of the day, Linux-Libre is just a regular package that can be
> > inherited and overridden like any other :-)
> 
> I think this is the approach we should promote for now.  I would prefer
> to leave 'make-linux-libre' as an internal implementation detail, and
> hopefully one with a limited life span.

Is it also possible to leave make-linux-libre out of the 2nd method presented in
the blog? I can't see any way to modify extra-options without it since in the
package it appears deeply nested inside arguments.