[aur-general] kernel updates render package obsolete
I'm maintaining the module package fsaa1655g (http://aur.archlinux.org/packages.php?ID=8281), a job I took over as the package had for all intents and purposes been abandoned. My problem is that every time the kernel is updated - even the smallest update - the package becomes obsolete. I'm pretty ignorant of these things but I suppose that is how things are for some (a lot? all?) non-kernel-modules. The particular problem with this module is that my laptop depends on it for wireless access (it turns on the wireless radio) and so when the kernel is upgraded and the module isn't immidiately upgraded with it, the laptop is restarted, the result is no wireless - which can make it hard to get the module upgraded for one thing. So I guess my questions are: 1) Is there some way around the module becoming outdated with each and every kernel update? and if not 2) For myself, I can just keep the source code on my drive and rebuild it whenever this happens - but is there some way of altering the PKGBUILD to do the same? 3) Any other way around the issue apart from quickly updating the package whenever there's a kernel upgrade? - Mads
You can always use HoldPkg = kernel26 in pacman.conf This will stop the kernel from being automatically upgraded. -- Abhishek On 17/11/2008, Mads Michelsen <chochem@gmail.com> wrote:
I'm maintaining the module package fsaa1655g (http://aur.archlinux.org/packages.php?ID=8281), a job I took over as the package had for all intents and purposes been abandoned.
My problem is that every time the kernel is updated - even the smallest update - the package becomes obsolete. I'm pretty ignorant of these things but I suppose that is how things are for some (a lot? all?) non-kernel-modules. The particular problem with this module is that my laptop depends on it for wireless access (it turns on the wireless radio) and so when the kernel is upgraded and the module isn't immidiately upgraded with it, the laptop is restarted, the result is no wireless - which can make it hard to get the module upgraded for one thing.
So I guess my questions are: 1) Is there some way around the module becoming outdated with each and every kernel update? and if not 2) For myself, I can just keep the source code on my drive and rebuild it whenever this happens - but is there some way of altering the PKGBUILD to do the same? 3) Any other way around the issue apart from quickly updating the package whenever there's a kernel upgrade?
- Mads
On Mon, Nov 17, 2008 at 10:47 AM, Mads Michelsen <chochem@gmail.com> wrote:
So I guess my questions are: 1) Is there some way around the module becoming outdated with each and every kernel update? and if not
Such is the pain of maintaining out-of-tree kernel modules. It sucks, I know. One thing that we do with our kernel modules, to make this easier, is we set the version to "2.6.27" instead of "2.6.27.8" so that when .9 is released, we don't need to rebuild all modules (they still need to be tested, however)
Aaron Griffin wrote:
On Mon, Nov 17, 2008 at 10:47 AM, Mads Michelsen <chochem@gmail.com> wrote:
So I guess my questions are: 1) Is there some way around the module becoming outdated with each and every kernel update? and if not
Such is the pain of maintaining out-of-tree kernel modules. It sucks, I know.
One thing that we do with our kernel modules, to make this easier, is we set the version to "2.6.27" instead of "2.6.27.8" so that when .9 is released, we don't need to rebuild all modules (they still need to be tested, however)
That's just trying to circumvent the restrictions that the kernel imposes on out-of-tree modules. A kernel API could be changed between minor versions too, and if a module uses a newer API call with older values, it would result in an oops. Sujith -- http://sujith-m.blogspot.com
One way that you can prevent yourself from forgetting it to also put depends=(kernel26<=2.6.N), so that it requires a specific version range.
Mads Michelsen schrieb:
So I guess my questions are: 1) Is there some way around the module becoming outdated with each and every kernel update? and if not
You only have to rebuild with major updates (which happen every 3 months).
2) For myself, I can just keep the source code on my drive and rebuild it whenever this happens - but is there some way of altering the PKGBUILD to do the same? 3) Any other way around the issue apart from quickly updating the package whenever there's a kernel upgrade?
All you can do is prevent anyone from accidently updating: depends=('kernel26>=2.6.27' 'kernel26<2.6.28') Once a major update occurs, pacman will refuse to update the kernel26 package unless you -Ud a newer one (with correct depends) first.
On Mon, 17 Nov 2008 19:21:00 +0100 Thomas Bächler <thomas@archlinux.org> wrote:
Mads Michelsen schrieb:
So I guess my questions are: 1) Is there some way around the module becoming outdated with each and every kernel update? and if not
You only have to rebuild with major updates (which happen every 3 months).
2) For myself, I can just keep the source code on my drive and rebuild it whenever this happens - but is there some way of altering the PKGBUILD to do the same? 3) Any other way around the issue apart from quickly updating the package whenever there's a kernel upgrade?
All you can do is prevent anyone from accidently updating:
depends=('kernel26>=2.6.27' 'kernel26<2.6.28')
Once a major update occurs, pacman will refuse to update the kernel26 package unless you -Ud a newer one (with correct depends) first.
Thanks for the replies. I just had the opportunity to test it with 2.6.27.6-1 and the old module still works, like Aaron said - where I thought I'd noticed previous minor upgrades reject it (strange...) - so that's some comfort. I'll use Thomas' suggestions of depends=('kernel26>=2.6.27' 'kernel26<2.6.28') - I think I preivously tried kernel26=2.6.27 but I believe that was interpreted very literally.
participants (6)
-
Aaron Griffin
-
Abhishek Dasgupta
-
Daenyth Blank
-
Mads Michelsen
-
Sujith
-
Thomas Bächler