Re: Kernel config dependencies?
Mark Bainter <[email protected]> Wed, 2 Jul 2003 23:22:48 -0500
| Newsgroups | gmane.linux.zynot.general |
|---|---|
| Message-ID | <[email protected]> |
Mark Gordon [[email protected]] wrote: >> [snip interesting idea about kernel option dependencies in ebuilds] > > Warning that you don't have the required support would be reasonable, > however I don't think I would like having an ebuild mess with my kernel > configuration for the following reasons: > > 1) The package might be for use with a kernel I am testing but not the > kernel I currently boot in to by default. > > 2) Some options in the kernel can be either deliberately or accidentally > incompatible with others, and only I am likely to know how I want > such issues resolved. > I wholeheartedly agree with this. I think the idea is interesting though. I think instead of dependencies we should make it special instructions at the end of the ebuild... *** *** Note: This software requires I2C support in the kernel (CONFIG_I2C) *** and this is not currently available in your kernel. Please *** be sure that this option is enabled in the kernel you *** attempt to run the software on, or it will not run properly. *** > 3) Assuming everything is OK I still need to know about the required > option and do manual rebuilds because I generally have an overlap of > at least a couple of weeks before I uninstall the previous kernel > after an upgrade. > > 4) Kernel options sometimes change name, or move, and I would imagine > this is an even bigger issue between 2.4 and 2.5. I think maybe the best way to handle this is on a case by case basis. You can check for the module availability fairly easily, and most of the other options that would be important for software are probably able to be verified via the /proc interface. I don't think there's a way you can query the running kernel for the options it was built with, and you can't assume /usr/src/linux/.config mirrors the current kernel. Well...there is that patch that makes the config available through /proc, but there's no guarantee a user will be running that.