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
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-2.6.16.18-tux_squashfs_citiall2-i386" 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
Hello Ryan, I think this solution is the best if we are not going to make any changes to pkgadd. 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) version=0.15.4cvs1 release=2 source=(http://dl.sourceforge.net/sourceforge/dxr3/em8300-0.15.3.tar.gz 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-2.6.16.23" 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. Alan 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-2.6.16.18-tux_squashfs_citiall2-i386" 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
Wouldn't a rule in /etc/pkgadd.conf help here? Something like: UPGRADE ^lib/modules/.*$ NO Not sure if this will solve your problem entirely, it depends on pkgadd and the way it handles installing to different directories. HTH, Joe
El Domingo, 2 de Julio de 2006 12:31 AM, Joe Gilmour escribió:
Wouldn't a rule in /etc/pkgadd.conf help here?
Something like:
UPGRADE ^lib/modules/.*$ NO
Not sure if this will solve your problem entirely, it depends on pkgadd and the way it handles installing to different directories.
HTH,
Joe
I already tried this, expecting the new module to be kept in /var/lib/pkg/rejected, but this didn't even happen. The old module was deleted and the new one took its place. Did I do something wrong? Is this working for you? Alan
participants (3)
-
Alan Mizrahi -
Joe Gilmour -
Ryan B. Lynch