[pacman-dev] Handling modules

[Aaron Griffin]

On 3/9/07, Jürgen Hötzel <juergen at hoetzel.info> wrote:
> On Fri, Mar 09, 2007 at 10:48:35AM -0600, Aaron Griffin wrote:
> > 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).
>
> I recommend a more gerneral solution. A buildsystem/package manager should
> not be aware of kernels, just packages.
>
> > 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.
>
> The decision which modules to install should be left to the user, maybe he
> wants modules installed for the stock kernel but not for another release.
>
> > - 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
>
> Just keep it the arch way: freedom of choice, user-controlled package
> management. Package management should not make any assumption about
> optional packages.
>
> I wrote a patch (enclosed) for makepkg to implement some kind of
> metapackages. This is a more general solution than a module-specific way.
>
> I attached ndiswrapper PKGBUILD/metscripts for stock an ck kernels to illustrate my
> ideas.
>
> This way we could also implement subpackages with a single PKGBUILD.
>

I really like this idea better.  See, this is why we discuss things, heh.

I dunno if I like the naming though... maybe something that fits the
scheme a bit better?

PKGBUILD -> METABUILD.foo ? Just suggesting here...

Also, we'd probably want to add some protection in there to verify
that, if it has sub-packages, the PKGBUILD isn't attempted without the
meta file... for instance, the pkgname=ndiswrapper${subname} could
cause some issues if subname is undefined.