Packages for kernel drivers

Alan Mizrahi alan-crux at
Sun Jul 2 16:59:29 UTC 2006

Hello Ryan,

I think this solution is the best if we are not going to make any changes to 

Maybe this is the way all the package maintainers should go for packages that 
contain kernel drivers.

I already tried this approach using this for the Pkgfile:

name=em8300-k$(uname -r)
em8300-ntsc.diff em8300_2.6.17_2.patch.gz)

This gives me a package named "em8300-k2.6.16.23#0.15.4cvs1-2.pkg.tar.gz"

I think the kernel version should be after the real package name, because it 
is like a part of the version.  Also I didn't write the 
whole "kernel-" string in order to save some space, I just 
abbreviated it with "k".

Here you can see another headache of mine: using a cvs version.  In this case 
its just a single picked patch from cvs, but sometimes you want the whole cvs 
release, and thats a pain to do unless the website have some snapshots ready 
for download.


El Sábado, 1 de Julio de 2006 5:15 PM, Ryan B. Lynch escribió:
> Alan,
> Although this is really far outside what you're supposed to do with
> pkgmk, I used a slightly different solution to address these kinds of
> problems.  Originally, it was a method to have multiple kernel
> builds/versions installed at the same time, and I've also started using
> it to support multiple versions of extra-kernel driver packages.
> The basic idea is that instead of having a single port, and incrementing
> the version number to reflect the actual version of the extra-kernel
> package, you have a different port (and hence a different package) for
> each version.  Here's an example of the kernel package I use:
>     package name:  "kernel-"
>     package version: "2"
> The name of the package is just "kernel-" suffixed with the kernel
> release version (the "real" version), a text string specifiying which
> patches I'm using, and the arch.  The "2" version means that it's the
> 2nd version I built (I didn't like the original config options, or
> something like that).  When I want to add a 2.6.17 kernel, the name
> becomes:
>     package name:  "kernel-2.6.17-tux_squashfs_citiall2-i386"
>     package version: "1"
> As long as you're careful in the Pkgfile to make sure that no two kernel
> packages stomp on each others' files, everything works pretty well.
> This should work the same way for any extra-kernel packages that you
> want to build.
> There are weaknesses in this approach:  the package names get kind of
> long and unwieldy, and the package version number has no relationship to
> the actual software version number, so I wouldn't recommend using it for
> any packages in the standard ports collections.  You wouldn't be able to
> use prt-get or pkginfo to determine whether a new version of the package
> exists, you'd have to look for yourself at the ports tree.  But these
> are because of the way Crux's package management system works.  I don't
> think that you could have a more sophisticated solution without making
> Crux package management a lot more complex.
> If anyone is curious, I could post some Pkgfile examples.
> -Ryan
> Alan Mizrahi wrote:
> > Hi there,
> >
> > As most of you, when I update my kernel version I keep the old one for
> > some time, just in case something goes wrong.
> >
> > The problem is that lately things have gone wrong too often, and
> > switching kernel versions isn't as easy as it should be if you are using
> > outside kernel drivers installed through crux packages.
> >
> > For example, if you are using the nvidia driver, you can't have it
> > installed in /lib/modules/linux-2.6.16 and /lib/modules/linux-2.6.17 at
> > the same time, because when pkgadd updates the package it removes it from
> > the old kernel tree.
> >
> > If it were just one package to rebuild each time, I wouldn't care, but in
> > my case I am using 4 packages with kernel drivers: nvidia, truecrypt,
> > em8300 and lirc.
> >
> > One way to solve this problem would be adding some code into pkgadd so
> > that it never deletes files in /lib/modules/<kernel-version> when
> > updating packages.
> >
> > Another idea would be to add a new rule tag to pkgadd.conf to let you
> > define which directories should be treated this way (but I don't find any
> > usefullness for this other than the kernel drivers).
> >
> > Maybe the whole idea of using packages for kernel drivers is not good,
> > what do you think?
> >
> >
> > Regards,
> >
> > Alan

More information about the CRUX mailing list