| 1 |
configs should have never gotten into genkernel in the first place. |
| 2 |
it's each kernel pkg (or even version) that owns a valid config of |
| 3 |
itself. |
| 4 |
I am part of genkernel@ but I have no will nor time to fix it. And |
| 5 |
when I have, I'd rather work on genkernel-next, that comes with a much |
| 6 |
more readable initramfs code (that I managed to rewrite myself). |
| 7 |
|
| 8 |
Wiping the whole config files has been on my agenda for very long time already. |
| 9 |
|
| 10 |
On Fri, May 30, 2014 at 6:32 PM, Rich Freeman <rich0@g.o> wrote: |
| 11 |
> On Fri, May 30, 2014 at 1:02 PM, Ben Kohler <bkohler@×××××.com> wrote: |
| 12 |
>> As nice at it sounds to just DROP these configs, that option is not really |
| 13 |
>> feasible considering the way we currently use genkernel in our handbook. |
| 14 |
>> Relying on the kernel's own defconfig, "genkernel all" will NOT produce the |
| 15 |
>> same mostly-usable-on-any-hardware result that we now rely on. |
| 16 |
> |
| 17 |
> Considering that the configs are more generically useful than |
| 18 |
> genkernel, having them separately maintained sort-of makes sense. |
| 19 |
> Then genkernel is a kernel build/install/initramfs tool, not a config |
| 20 |
> management tool. |
| 21 |
> |
| 22 |
> I'd stick them someplace where any dev can get to them, and separate |
| 23 |
> them from the genkernel functional code base. |
| 24 |
> |
| 25 |
> As far as who takes care of them goes - I suggest that this stuff |
| 26 |
> comes out of the devmanual unless somebody steps up to take care of |
| 27 |
> them. Those who take care of them become those who want to keep them |
| 28 |
> around. You can't toss out a tool and ask for it to be a |
| 29 |
> recommendation but point to others that you think need to maintain its |
| 30 |
> configuration. |
| 31 |
> |
| 32 |
> Rich |
| 33 |
> |
| 34 |
|
| 35 |
|
| 36 |
|
| 37 |
-- |
| 38 |
Fabio Erculiani |
Archives