John Mylchreest wrote: > 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? Maybe just append to a file in /etc/portage? What would require changes to portage? Seems like an automation tool would be mostly seperate from portage. > > This way, we can pretty much automate it as my previous example, without > needing to worry about userland or firmware overhead at all. > And it would be much of a transition for users, just getting devs to do what they should have done from the begining :-).
-- Michael Marineau [EMAIL PROTECTED] Gentoo Linux Developer Oregon State University
signature.asc
Description: OpenPGP digital signature
