Gentoo Archives: gentoo-dev

From: Peter Johanson <latexer@g.o>
To: Stefan Schweizer <sschweizer@×××××.com>
Cc: Henrik Brix Andersen <brix@g.o>, gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] kernel-mod.eclass addition + clean up
Date: Fri, 29 Oct 2004 15:36:05
Message-Id: 20041029153603.GA8791@butchy.cubesearch.com
In Reply to: Re: [gentoo-dev] kernel-mod.eclass addition + clean up by Stefan Schweizer
1 On Fri, Oct 29, 2004 at 01:04:14PM +0200, Stefan Schweizer wrote:
2 > On Fri, 29 Oct 2004 12:55:57 +0200, Henrik Brix Andersen
3 > <brix@g.o> wrote:
4 > > I've written a patch for the kernel-mod.eclass to automatically call
5 > > 'depmod' in pkg_postinst() for ebuilds enheriting kernel-mod. Ebuilds
6 > > that wish to override pkg_postinst() can call kernel-mod_depmod() on
7 > > their own.
8 > Not all ebuilds inheriting kernel-mod build modules so not all of them
9 > may want to run depmod after compiling.
10
11 The goal of kernel-mod eclass is to enable kernel module ebuilds to have
12 an easier time doing what they do. If non-kernel module ebuilds are
13 using kernel-mod, we should investigate what functionality *those*
14 ebuilds use, and move that into a seperate eclass that kernel-mod.eclass
15 can then inherit from. Things like the kernel version variable
16 detection, etc, is what i'm guessing is used by other ebuilds (i don't
17 have time to dig currently) and we could certainly move that into
18 kernel-info.eclass or somesuch, and let kernel-mod.eclass inherit that.
19 Then we are free to do things like brix suggests, without annoying those
20 few ebuilds that think they are kernel module ebuilds, but are really
21 imposters. (:
22
23 Comments?
24
25 -pete
26
27 >
28 >
29 > -Stefan
30 >
31 > --
32 > gentoo-dev@g.o mailing list
33 >
34
35 --
36 Peter Johanson
37 <latexer@g.o>
38
39 --
40 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] kernel-mod.eclass addition + clean up Henrik Brix Andersen <brix@g.o>
Re: [gentoo-dev] kernel-mod.eclass addition + clean up Henrik Brix Andersen <brix@g.o>