Gentoo Archives: gentoo-soc

From: Patrick Lauer <patrick@g.o>
To: gentoo-soc@l.g.o
Subject: Re: [gentoo-soc] Application for Google Summer of Code 2018-Mishal Roy
Date: Fri, 23 Mar 2018 06:50:50
Message-Id: 1dffb6d3-37ad-b892-af60-5741a83830ca@gentoo.org
In Reply to: Re: [gentoo-soc] Application for Google Summer of Code 2018-Mishal Roy by Rich Freeman
1 On 03/22/2018 04:25 PM, Rich Freeman wrote:
2 > On Thu, Mar 22, 2018 at 12:07 AM, Benda Xu <heroxbd@g.o> wrote:
3 >>
4 >>> builds x86 linux kernel from source code present in /usr/src/linux
5 >>> directory of Gentoo liveDVD
6 >>
7 >> This is not how Gentoo ebuild works, the build should prepare the source
8 >> code.
9 >>
10 >
11 > I don't want to derail whatever your goals are here, but IMO an ebuild
12 > that actually builds a kernel would be useful.
13 >
14
15 https://github.com/adjust/gentoo-overlay/tree/master/sys-kernel
16
17 This just needs to be cleaned up a bit to be upstreamed, and so far I've
18 not had the time for it.
19
20 It's a solved problem (I'm aware of at least two other ebuilds to do the
21 same) :)
22
23 > However, such an ebuild shouldn't touch /usr/src. If I were doing a
24 > kernel build ebuild I'd have it fetch kernel sources like any other
25 > package, then build it in the normal location, with configuration
26 > options provided via USE flags or some default config, and then
27 > install the final kernel in /boot.
28 >
29 > I realize that isn't how Gentoo has done it for the last 20 years, but
30 > I've always thought that it would make sense to have a way to actually
31 > maintain up-do-date kernels in the same manner as any other package,
32 > with the /usr/src approach being an also-supported alternative.
33 >
34 > That said, there are complications. Some kernel modules want prepared
35 > (or even built) sources and this approach would clean those after
36 > install. Also, we'd probably need to use subslots for initramfs
37 > rebuilds or something like that. I suspect this is why it hasn't been
38 > done yet.
39 >
40 > Again, I don't want to derail SoC with this unless there was an intent
41 > to actually build a kernel this way...
42 >

Replies