Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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
Task Type Feature Request
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

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:
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.
Comment by Eric Barrat (nowahn) - Sunday, 29 March 2009, 20:51 GMT
OK, I have just understood that this PKGBUILD allows us to install several kernels without conflicts, and then boot with either one or the other. so just forget the 'conflicts' line.
Comment by Roman Kyrylych (Romashka) - Sunday, 31 May 2009, 13:43 GMT
I haven't used lilo since long time ago, but AFAIR there is a message about running lilo when upgrading kernel.
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?
Comment by Tobias Powalowski (tpowa) - Sunday, 31 May 2009, 13:45 GMT
i don't see a reason for adding this here too, thomas an opinion?
Comment by Roman Kyrylych (Romashka) - Sunday, 31 May 2009, 13:48 GMT
oh, and about the modules - I have thought about a message about kernel modules being in another directory now and providing some hint for a user about that,
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.
Comment by Eric Barrat (nowahn) - Friday, 02 October 2009, 07:43 GMT
Up. (bug squashing day coming)
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.
Comment by Thomas Bächler (brain0) - Friday, 02 October 2009, 08:33 GMT
The conflicts/provides is wrong, different kernels must have a different pkgname. There's already methods in place to make this more comfortable, by just changing one variable at the beginning.

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.

Loading...