You are not logged in.
So, the package virtualbox-host-modules in community lists a specific kernel in it's dependancies:
linux<3.6
linux>=3.5
I'm currently using a custom kernel, version 3.5.2 and have the stock kernel uninstalled. Shoudn't pacman be able to detect my kernel and not force me to install the stock kernel again when installing the package?
Last edited by silverwind (2012-10-09 14:17:49)
Offline
Is your custom kernel named 'linux' or provides linux? Did you install it using a PKGBUILD?
Offline
Pacman doesn't "detect" anything on your system, it just knows what's in it's database. How about using the abs to make the kernel?
Online
No, it's actuall named linux-netbook (an aur package). Installing from a PKGBUILD would work, and I know how to solve this, I was just wondering why the package depends on the stock kernel itself. Isn't there a cleaner way to define it?
Offline
Pacman doesn't "detect" anything on your system, it just knows what's in it's database. How about using the abs to make the kernel?
Ah, thats what I get from using AUR packages directly. I'll have a look into that, thanks.
Offline
There's no package named linux-netbook in the AUR.
If the package provides linux, there shouldn't be a problem. It's the same way e.g. bash provides sh.
Offline
I was just wondering why the package depends on the stock kernel itself.
Because the package installs things into /usr/lib/modules/extramodules-3.6-ARCH which of course is specific to the linux package.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
If you're installing from the AUR, the PKGBUILD should say that it provides "linux". If it doesn't, it's a bug that needs to be fixed. I don't see the package you mentioned in the AUR, though.
When I mentioned using the abs, I was thinking more for making an actual custom kernel, ie one you customize yourself. If you're using something someone else did, it shouldn't be an issue.
Online
oh sorry, the package is actually named kernel-netbook:
https://aur.archlinux.org/packages.php?ID=34625
edit: hmm, strange the PKGBUILD includes
provides=('linux')
Last edited by silverwind (2012-10-09 00:48:56)
Offline
If you're installing from the AUR, the PKGBUILD should say that it provides "linux". If it doesn't, it's a bug that needs to be fixed. I don't see the package you mentioned in the AUR, though.
When I mentioned using the abs, I was thinking more for making an actual custom kernel, ie one you customize yourself. If you're using something someone else did, it shouldn't be an issue.
It SHOULD NOT say that it provides 'linux' UNLESS it really provides the same files and reads the same modules, otherwise it doesn't really provide the package named 'linux'.
And the specific error in this case is because generically providing A does not provide version X.Y.Z of A, so versioned deps will still fail.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
Turn out I was doubly wrong, as linux package actually provides 'kernel26=3.x.y'., so it's 'kernel26' and not 'linux' and it seems the version number is mandatory.
Offline
Turn out I was doubly wrong, as linux package actually provides 'kernel26=3.x.y'., so it's 'kernel26' and not 'linux' and it seems the version number is mandatory.
pkgbase=linux
_kernelname=${pkgbase#linux}
provides=("kernel26${_kernelname}=${pkgver}")
Shouldn't it read provides=("kernel26linux=x.y.z") ?
Offline
Take a look at the linux PKGBUILD: https://projects.archlinux.org/svntogit … ages/linux
pkgver=3.6.1
...
provides=("kernel26${_kernelname}=${pkgver}")
$ pacman -Qi linux | grep Provides
Provides : kernel26=3.6.1
(I'm using [testing]).
Offline
the virtualbox packages don't depend on "kernel26", though, they depend on "linux".
Online
Hmm, not sure what the # operator does in that script. Anyways, thanks - I'll forward this to the maintainer.
Offline
Hmm, not sure what the # operator does in that script.
Offline
the virtualbox packages don't depend on "kernel26", though, they depend on "linux".
You asked for a cleaner way https://bbs.archlinux.org/viewtopic.php … 3#p1172743 - you can specify either linux or the old kernel26 as a dependency.. I guess this way old stuff that depended on kerlen26 may still work.
Hmm, not sure what the # operator does in that script.
${parameter#word}
${parameter##word}
Remove matching prefix pattern. The word is expanded
to produce a pattern just as in pathname expansion. If
the pattern matches the beginning of the value of
parameter, then the result of the expansion is the
expanded value of parameter with the shortest matching
pattern (the ``#'' case) or the longest matching pat‐
tern (the ``##'' case) deleted. If parameter is @ or
*, the pattern removal operation is applied to each
positional parameter in turn, and the expansion is the
resultant list. If parameter is an array variable sub‐
scripted with @ or *, the pattern removal operation is
applied to each member of the array in turn, and the
expansion is the resultant list.
In this case, the result is '' - i.e. nothing.
Offline
I'm still not sure what the core problem here is really, but could the 3.6 kernel I have also installed (but not running) be the culprit here?
Here's the package again:
pacman -Si virtualbox-host-modules
Name : virtualbox-host-modules
Version : 4.2.0-5
Depends On : linux>=3.5 linux<3.6
And here the running kernel:
pacman -Qi kernel-netbook
Name : kernel-netbook
Version : 3.5.2-1
Provides : linux
And the 3.6, also from AUR:
pacman -Qi linux-mainline
Name : linux-mainline
Version : 3.6-1
Provides : kernel26-mainline=3.6
Does 3.6 which provides kernel26 make the dependancy check fail?
Oh, and sorry for not mentioning the installed 3.6 earlier.
Last edited by silverwind (2012-10-09 01:51:41)
Offline
since it's not linux 3.6 but linux-mainline 3.6, I don't think that would do it. I wonder if editing the kernel-netbook PKGBUILD to include the version instead of just 'linux' would do it.
I really wonder if the simplest solution is just to build the modules yourself through the abs.
Last edited by Scimmia (2012-10-09 02:04:25)
Online
I'm still not sure what the core problem here is really
You're trying to install a module which is specifically for the ARCH kernel (see my previous post) and expecting your own non-stock kernel to magically detect that module even though its not in the correct extramodules-*-* folder.
In general, EVERY module is kernel specific. Pre-compiled kernel modules will only work on the stock ARCH kernel (or on an abs-modified version of it).
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
silverwind wrote:I'm still not sure what the core problem here is really
You're trying to install a module which is specifically for the ARCH kernel (see my previous post) and expecting your own non-stock kernel to magically detect that module even though its not in the correct extramodules-*-* folder.
In general, EVERY module is kernel specific. Pre-compiled kernel modules will only work on the stock ARCH kernel (or on an abs-modified version of it).
Ah, that clears it up then. No reason to try force installing these modules then. Thanks!
Offline
Are Arch's patches that extensive that they make major changes to the kernel headers? If not, the modules are not kernel specific, they're version specific (within reason). Assuming the modules are for the correct version of the kernel, the one kernel you're using has loadable module support, and it doesn't have major patching itself, the modules are very likely to work. The issue here has nothing to do with the modules themselves but with how pacman handles dependency resolution.
Last edited by Scimmia (2012-10-09 02:38:55)
Online
Are Arch's patches that extensive that they make major changes to the kernel headers? If not, the modules are not kernel specific, they're version specific (within reason). Assuming the modules are for the correct version of the kernel, the one kernel you're using has loadable module support, and it doesn't have major patching itself, the modules are very likely to work. The issue here has nothing to do with the modules themselves but with how pacman handles dependency resolution.
The modules are not kernel specific. Their location is. Arch packages aren't simply files, they're files in particular locations. AFAICR kernels search for modules only within specific directories by default.
Of course, it would be possible to make modules general with an expansion of the current extramodules structure, but that's beyond the scope of this topic (not to mention, IMO, a really bad idea).
@silverwind - please mark the topic as [solved] by editing your first post and changing the title
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline
In this case, though, it would be a matter of a single missing symlink, assuming the kernel package in question doesn't create it.
Last edited by Scimmia (2012-10-09 03:19:02)
Online
In this case, though, it would be a matter of a single missing symlink, assuming the kernel package in question doesn't create it.
Why would the kernel package create a module-specific symlink? Unless you're talking about symlinking the extramodules folder, which would problematic since that would be all-or-nothing in terms of which modules are available.
Allan-Volunteer on the (topic being discussed) mailn lists. You never get the people who matters attention on the forums.
jasonwryan-Installing Arch is a measure of your literacy. Maintaining Arch is a measure of your diligence. Contributing to Arch is a measure of your competence.
Griemak-Bleeding edge, not bleeding flat. Edge denotes falls will occur from time to time. Bring your own parachute.
Offline