[pacman-dev] Handling modules

[Aaron Griffin]

On 3/9/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> On 3/9/07, James <iphitus at 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?