You are not logged in.
Pages: 1
Lets say kernel26-matroxfb has matroxfb compiled as a module. And let's say kernel26-audit has auditing support compiled into the kernel. Someone who wants both of these will have to edit .config and compile their kernel. After this depending on what he or she named the package, matrox framebuffer packages would complain about no kernel26-matroxfb and/or auditing packages would complain about no kernel26-audit leading to alot of -d and -f flags required for pacman from then on.
What if the entire config file was parsed as part of the PKGBUILD for all Arch kernels? This would populate the "provides" list of the package so the person's custom kernel would have provides=(..., kernel26-fb-matrox-m, ..., kernel26-audit-y, ...) built into their package. That way any program requiring a kernel to have CONFIG_X_Y=z could just have depends=(kernel26-x-y-z) instead of depends=(some kernel put in the AUR by that person which works with that package due to some elusive config that someone has to search endlessly for if they want to use a custom kernel with it). I know we don't want pacman -Q | grep kernel26 to show thousands of entires. That's why I think "provides" is the best solution because it doesn't add each virtual package to that list.
Is this a good idea? Tell me if I'm explaining it badly. If you'd consider implementing this if someone wrote the script, I'd gladly do it.
6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.
Offline
I wrote a script once that took the default package for a kernel module and compiled it for another kernel. I really should dig it out, though it's been ages since I did any kernel work and I have no idea how well it would work now.
Offline
I thought I'd make an example to show this. Please check out my kernel26-kms PKGBUILD and my audit package both in the AUR.
6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.
Offline
Pages: 1