FS#13987 - [kernel26] PKGBUILD and .INSTALL improvments
Attached to Project:
Arch Linux
Opened by Eric Barrat (nowahn) - Friday, 27 March 2009, 16:18 GMT
Last edited by Thomas Bächler (brain0) - Friday, 02 October 2009, 08:34 GMT
Opened by Eric Barrat (nowahn) - Friday, 27 March 2009, 16:18 GMT
Last edited by Thomas Bächler (brain0) - Friday, 02 October 2009, 08:34 GMT
|
Details
Description:
PKGBUILD request: it would be useful to add this to lines: ------------------------------------------------------------------------- # provides=("kernel26=${pkgver}-${pkgrel}") # uncomment for custom kernel # conflicts=('kernel26') # uncomment for custom kernel ------------------------------------------------------------------------- (or is there any reason not to include these lines ?) .INSTALL request: since the new kernel PKGBUILD change the kernel release (I mean the output of `uname -r`), it would be useful to display these two warnings at installation or update time: - need to update bootloader config file - kernel modules migration (from /lib/modules/2.6.28-ARCH to /lib/modules/2.6.28-<custom> I have done this to the kernel I maintain in AUR using the attached patch (to be applied with patch -Np1 -i from ${startdir}) (I think that [ `uname -r` != "${KERNEL_VERSION}" ] would be a better test than the one I have written) PS: thanks for this PKGBUILD change, it is very easy to create a custom kernel package now ;-) Additional info: * package version(s) kernel26 2.6.28.8-1 * config and/or log files etc. Steps to reproduce: 
install.patch
(3.8 KiB)
|
This task depends upon
Closed by Thomas Bächler (brain0)
Friday, 02 October 2009, 08:34 GMT
Reason for closing: Won't implement
Additional comments about closing: See last comment, this is the wrong way to do it.
Friday, 02 October 2009, 08:34 GMT
Reason for closing: Won't implement
Additional comments about closing: See last comment, this is the wrong way to do it.
As for modifying grub's config - this is not needed for the default kernel, and if you're running a customized kernel - you're free to add any code that makes your life easier to the customized PKGBUILD anyway (including the provides line), I'm not convinced that there should be any helper code for this in the default kernel PKGBUILD.
@Tobias: your opinion on this?
e.g. I often got myself in a situation when after upgrading the (default) kernel my flash device or CDMA USB modem won't get recognized properly after reattaching - because udev was expecting modules to be in the old directory which was now deleted.
But I'm not sure if this is worth adding to post_upgrade and what the recommendation for a user should be.
I actually agree with Roman and Tobias for not including this to the default kernel.
So maybe this request should be closed with 'not implemented' status.
Instead of having the weird post_install on uname -r change, we should rather add a virtual provides= name for the kernel version and have modules depend on it.