View previous topic :: View next topic |
Author |
Message |
sparc n00b
Joined: 18 Aug 2005 Posts: 72 Location: Stockholm, Sweden
|
Posted: Tue Mar 02, 2010 1:31 pm Post subject: Set of kernel-sources dependent packages? |
|
|
Hi,
Is there a set for rebuilding all the packages which are dependent on the Kernel sources or configuration?
I'll give an example of a situation that made this a necessity. I'm running a 2.6.31 kernel. I downloaded a 2.6.32 version and while making the configuration I did an 'emerge world' update. I was anxious to go through all the new staff in the kernel so I didn't pay much attention to the package list. Among the updated packages where some that were dependent on the kernel-sources, which at that point had an empty configuration (no .config file and no Makefile at all) and what was worse those packages didn't seriously complain about it (like stop compiling). Such a package is hal which only prompted a warning.
As a result, powerdevil broke. It took me ages to realize what happened. Now the solution seems obvious, I simply had to recompile hal against a proper kernel configuration. However, the 2.6.32 kernel was not a good match for my laptop as the internal microphone disappeared. So, I had to go back to the .31 kernel.
I'm not saying that this is not my mistake. It is a huge mistake but such things happen. So it would be convenient for such a set to exist. Much like the @modules-rebuild set.
Now, I do not really know what each package is looking in the sources but I guess it is possible that some are actually configuring themselves according to the kernel and for that reason if a kernel update alters specific parts of an API (or ABI), those packages would have problems. So I guess it would be helpful to emerge that set after every kernel configuration/version change. Especially since the kernel is such a gray area for many of us
regards |
|
Back to top |
|
|
Jaglover Watchman
Joined: 29 May 2005 Posts: 8291 Location: Saint Amant, Acadiana
|
Posted: Tue Mar 02, 2010 2:05 pm Post subject: |
|
|
Is this what you want?
Code: | emerge -av1 $(qdepends -CNQ virtual/linux-sources) |
|
|
Back to top |
|
|
sparc n00b
Joined: 18 Aug 2005 Posts: 72 Location: Stockholm, Sweden
|
Posted: Tue Mar 02, 2010 2:41 pm Post subject: |
|
|
Not even close... Your command will give the packages that depend on the sources to actually exist. In my case it was the packages that create modules.
What I'm referring to are packages that are specially configured against the active kernel configuration or Makefile. For example there are packages that will refuse to build if a specific option in the kernel is not set. Others, like hal, are greatly dependent on the kernel Makefile and/or .config files.
You can try it yourself. clean your kernel and reemerge hal. Many acpi-related staff will stop working in userland (like suspend, hibernate, brightness and cpu-freq scaling). You do not even have to reboot or recompile the kernel. Absent a Makefile in /usr/src/linux hal totally breaks (for a reason that I do not know) .
I'm asking for a set that includes those packages. Packages that might break if the kernel configuration is changed. |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9532 Location: beyond the rim
|
Posted: Wed Mar 03, 2010 3:43 am Post subject: |
|
|
Well, there are two things that together might give you the wanted result (all assuming you're using portage-2.2, with 2.1 it's not possible):
- the predefined @module-rebuild set to rebuild packages with kernel modules
- you can define another set @kernel-related to include all packages that inherit the linux-info class (which provides the functions to check for kernel stuff) by adding the following section to your /etc/portage/sets.conf:
Code: | [kernel-related]
class = portage.sets.dbapi.VariableSet
variable = INHERITED
includes = linux-info
world-candidate = False |
However this will likely include a number of false positives (not everything that inherits linux-info is kernel-dependant), so you might be better of using a manually maintained package list instead, using the above set to check for changes. And obviously if a package somehow depends on kernel stuff and doesn't use linux-info it won't get picked up by the above, but as long as you can find some way to detect such packages there usually is a way to create a set out of it. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|