Gentoo Archives: gentoo-soc

From: Mishal Roy <roymishal210@×××××.com>
To: Rich Freeman <rich0@g.o>
Cc: gentoo-soc@l.g.o
Subject: Re: [gentoo-soc] Application for Google Summer of Code 2018-Mishal Roy
Date: Thu, 22 Mar 2018 16:06:21
Message-Id: CAA-UPQs1Xmz-hEv6rH9-xoXTSaBXx+z24w3LC5mvJY5FUNPmHA@mail.gmail.com
In Reply to: Re: [gentoo-soc] Application for Google Summer of Code 2018-Mishal Roy by Rich Freeman
1 Hi,
2
3 I agree with you. That was not the right way of writing an ebuild. I had
4 posted it as a proof of concept. I don't intend to do so while writing an
5 ebuild for soc. The way I want to do has been given in my proposal. Please
6 go through it.
7
8 Thanks and Regards,
9 Mishal Roy.
10
11 On Thu, Mar 22, 2018, 8:55 PM Rich Freeman <rich0@g.o> wrote:
12
13 > On Thu, Mar 22, 2018 at 12:07 AM, Benda Xu <heroxbd@g.o> wrote:
14 > >
15 > >> builds x86 linux kernel from source code present in /usr/src/linux
16 > >> directory of Gentoo liveDVD
17 > >
18 > > This is not how Gentoo ebuild works, the build should prepare the source
19 > > code.
20 > >
21 >
22 > I don't want to derail whatever your goals are here, but IMO an ebuild
23 > that actually builds a kernel would be useful.
24 >
25 > However, such an ebuild shouldn't touch /usr/src. If I were doing a
26 > kernel build ebuild I'd have it fetch kernel sources like any other
27 > package, then build it in the normal location, with configuration
28 > options provided via USE flags or some default config, and then
29 > install the final kernel in /boot.
30 >
31 > I realize that isn't how Gentoo has done it for the last 20 years, but
32 > I've always thought that it would make sense to have a way to actually
33 > maintain up-do-date kernels in the same manner as any other package,
34 > with the /usr/src approach being an also-supported alternative.
35 >
36 > That said, there are complications. Some kernel modules want prepared
37 > (or even built) sources and this approach would clean those after
38 > install. Also, we'd probably need to use subslots for initramfs
39 > rebuilds or something like that. I suspect this is why it hasn't been
40 > done yet.
41 >
42 > Again, I don't want to derail SoC with this unless there was an intent
43 > to actually build a kernel this way...
44 >
45 > --
46 > Rich
47 >

Attachments

File name MIME type
gsoc.pdf application/pdf