1 |
pbg1854@×××××××××××××××.edu wrote: |
2 |
|
3 |
> Ok... |
4 |
> |
5 |
> How about we make an option to ebuild that makes the build process |
6 |
> interactive. We could make that option set a variable in the ebuild |
7 |
> script, which we would then check during the individual steps in the |
8 |
> process.. for example, |
9 |
> |
10 |
> if [ "${INTERACTIVE}" ]; then |
11 |
> make menuconfig |
12 |
> else |
13 |
> cp "${FILESDIR}/config-${KV}" ${WORKDIR}/linux/.config |
14 |
> yes "" | make oldconfig |
15 |
> fi |
16 |
|
17 |
Thats what I ment by the USE variable method. |
18 |
|
19 |
> |
20 |
> Then you could run ebuild -i merge or something like that. |
21 |
> |
22 |
|
23 |
We do not use flags for ebuild at the moment. Maybe in future |
24 |
|
25 |
> |
26 |
> A few notes: |
27 |
> I like using make oldconfig, because it automatically takes care of |
28 |
> autoconf.h, and version.h for you, and makes sure everything is |
29 |
> configured right. I'd use yes "" | make oldconfig in the |
30 |
> non-interactive version, that way if there are any variables missing |
31 |
> in the .config file, they will get the default value. |
32 |
|
33 |
That sounds good. I think I saw that option last week in some magazine. |
34 |
|
35 |
> |
36 |
> |
37 |
> I also thought it would be a good idea if the kernels were installed |
38 |
> with a suffix determining the version of the kernel, |
39 |
> i.e. bzImage-2.4.0 rather than just bzImage; that way multiple kernels |
40 |
> can be installed at the same time. I like to do this, especially when |
41 |
> installing a new kernel, in case the new one won't boot or has some |
42 |
> kind of bug in it, I can go back to the old one. Then you could merge |
43 |
> the new kernel, reboot, and unmerge the old one after you're satisfied |
44 |
> the new one works. |
45 |
|
46 |
But what if you configure manual and have different kernels of the same version? |
47 |
|
48 |
> |
49 |
> |
50 |
> If you want, I'll try to modify the ebuild script to add interactive |
51 |
> building support, and work on a sample kernel ebuild. Adding |
52 |
> interactive support shouldn't require any modifications in the |
53 |
> packages, I'm pretty sure. |
54 |
> |
55 |
> Oh... and one more thing... I'm having problems w/ the make check |
56 |
> stage while building glibc-2.2.1. I'm trying to figure out why right |
57 |
> now. It just says "Timed out" or something like that. I'll give you |
58 |
> more info after I run make check again. |
59 |
|
60 |
Hmm, sounds like LFS <-> low latency problem. I saw that over here once but at |
61 |
that time |
62 |
I had a lot of parallel build processes running. |
63 |
|
64 |
> |
65 |
> |
66 |
|
67 |
achim~ |
68 |
|
69 |
> |
70 |
> Pete |
71 |
> |
72 |
> On Mon, Feb 05, 2001 at 03:03:38PM +0100, Achim Gottinger wrote: |
73 |
> > Pete Gavin wrote: |
74 |
> > |
75 |
> > > Hi, |
76 |
> > > |
77 |
> > > I was wondering... Is it required that an ebuild script be completely |
78 |
> > > non-interactive? |
79 |
> > |
80 |
> > Yes, otherwise there would be no autobuild. |
81 |
> > |
82 |
> > > I have a few ideas for the kernel configuration |
83 |
> > > scripts. I think it might be cool for the for the ebuild to ask the |
84 |
> > > installer if he/she wants to load a .config file from somewhere else, then |
85 |
> > > run make menuconfig. That way all the modules and stuff can be removed |
86 |
> > > with portage-unmerge. |
87 |
> > |
88 |
> > You can do this. |
89 |
> > After running "ebuild linux.... unpack" cd to |
90 |
> > /tmp/portage/linux.../work/linux |
91 |
> > run "make menuconfig/xconfig" |
92 |
> > Then continue with ebuild linux... compile |
93 |
> > |
94 |
> > Another possibility would be using the "config" function in ebuild. This was |
95 |
> > normaly intedet to be used |
96 |
> > for an opional additional configuration-layer. And should normaly modify the |
97 |
> > package configuration |
98 |
> > files from templates/databses whatever. Normaly this functions hsould be |
99 |
> > called after pkg_merge. |
100 |
> > But since we have no configuration layer right now and config is only used by |
101 |
> > a few packages (for example |
102 |
> > qmail runs config-fast from within the config function) we could use the |
103 |
> > config function for such an |
104 |
> > interactive thing. |
105 |
> > Another solution could be using a USE variable to decide if the manual |
106 |
> > configuration you described should be |
107 |
> > run or a variable that just triggers if a private config file should be used |
108 |
> > instead of the default one. Or we could make a sepearate kernel package that |
109 |
> > does these manual steps. |
110 |
> > |
111 |
> > But what do you think about that. The kernel ebuild looks if a file (for |
112 |
> > example /etc/kernel/[version].config) exists. If so it uses this instead of |
113 |
> > the default one. |
114 |
> > If you want to configure the kernel for the first time you can do it as I |
115 |
> > described above. The copy the .config file to /etc/kernel/[version].config |
116 |
> > and the next time you compile the kernel your private config file gets used. |
117 |
> > |
118 |
> > achim~ |
119 |
> > |
120 |
> > > |
121 |
> > > Pete |
122 |
> > > |
123 |
> > > _______________________________________________ |
124 |
> > > gentoo-dev mailing list |
125 |
> > > gentoo-dev@g.o |
126 |
> > > http://www.gentoo.org/mailman/listinfo/gentoo-dev |
127 |
> > |
128 |
> > |
129 |
> > _______________________________________________ |
130 |
> > gentoo-dev mailing list |
131 |
> > gentoo-dev@g.o |
132 |
> > http://www.gentoo.org/mailman/listinfo/gentoo-dev |
133 |
> |
134 |
> _______________________________________________ |
135 |
> gentoo-dev mailing list |
136 |
> gentoo-dev@g.o |
137 |
> http://www.gentoo.org/mailman/listinfo/gentoo-dev |