On Tue, 2005-01-18 at 08:54 -0800, Michael Marineau wrote: > Which ever way is chosen as the preferred method, if it is automated then the > method won't matter to much. So I guess the important question is, which > method > is easier to implement, automate, and maintain?
Since all of this was spoke about last night a lot has changed in both my idea of this implementation and otherwise. I personally feel now that even though the source based install solution mentioned earlier will be more convenient to others than the overhead of portage, this should be dropped from the equation as a tool to achieve the goal of better automation, and to have it simply as a feature for those who want it. The actual policy which looks like being enforced here (since this is important with interfacing anything portage related to kernel sources) will be for modules to be split into sections. 1: ebuild-driver: the module to be compiled against, and installed for KERNEL_DIR. This should inherit linux-mod and use linux-mod functionality. 2: ebuild-utils: this is any userland tools which get bundled with the module. these should inherit linux-info and PDEPEND on ebuild-driver (in most cases) 3: ebuild-firmware: where a module requires firmware, then it is bundled in a seperate package. inherits linux-info where neccessary and PDEPENDS on ebuild-utils/driver depending on circumstance With relation to the automation side of this, I feel the better way to achieve this is for linux-mod to write the packagename it is working on into /var/lib/modules, if this functionality is then included into portage it can move to /var/lib/portage/modules. I will need to speak with the portage devs on this, any suggestions if your reading guys? This way, we can pretty much automate it as my previous example, without needing to worry about userland or firmware overhead at all. -- Role: Gentoo Linux Kernel Lead Gentoo Linux: http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 Web: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x9C745515
signature.asc
Description: This is a digitally signed message part
