On 3/9/07, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On 3/9/07, James <iphitus@gmail.com> wrote:
4) Modules. I still think that there has to be a better way of dealing with modules. We've put this discussion off once already saying "pacman3". Now pacman3-RC1 is upon us, it's time to start looking at how we can improve these, so that it can swiftly be implemented and included in future releases.
I have a proof-of-concept somewhere that checked a PKGBUILD for "build_module" instead of "build". If found, it runs it once for each kernel installed on the system (checking pacman first to make sure it is a real package and not a custom kernel). Couple this with repo-add which gets all information from the package (and does not need to know about the PKGBUILD) and this would be a real straightforward fix to building multiple modules with one PKGBUILD. Now the *real* question is - how do we install them? I can think of a decent use-case: $ pacman -S ndiswrapper - ndiswrapper is no longer a package. It is a group. Each package has a setting somewhere (TYPE="module" ??) indicating that this is a module. Pacman then loops through the group, if a packahe TYPE is "module", it checks to see if the kernel is installed. If it is, it adds it to the target list. - so the result would install ndiswrapper-ARCH, ndiswrapper-beyond, and ndiswrapper-thinkpad on my machine. One problem I can think of is as follows: pacman -S ndiswrapper - install ndiswrapper-ARCH pacman -S kernel26beyond - this should ALSO install ndiswrapper-beyond at the same time I'm not sure how to handle this... some actual empty package named "ndiswrapper" could be installed, with the type= set to "module". That could be used to check for deps and things of that nature when upgrading or installing a new kernel... Ideas? Thoughts?