You are not logged in.
For example, I was considering packaging the madwifi driver when another stable release is made (since it is apparently bad form to do it from CVS). However, it must be compiled for 2.6 and 2.4 kernels differently since it is a kernel module.
Is there a way to pick versions? For example, if `uname -r | grep 2.6` contains data (to avoid custom kernels and stuff not being detected), download the 2.6 version, or else the 2.4 version.
If not, is this why there are no kernel dependent packages?
Offline
Kernel packages are pretty difficult that way. Back when there was just 2.4 it wasn't a problem. Everything was compiled against the stock kernel. Now that there's 2.6 the jury's still out on what to do. If you have a suggestion, feel free. Keep in mind that maintaining multiple versions of the same package sucks.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
I think the easiest solution would be to modify pacman a bit.
Create two packages - package24 and package26 (this follows the kernel naming scheme)
pacman detects the kernel (hopefully not only through installed packages), and downloads the correct package.
Just compile against the stock kernel package, and it should all work fine. I don't see why not having "SCSI RAID" capability enabled in a custom kernel would change anything to do with a custom module, and if you've gone custom, presumably you know enough to fix the problem.
Offline
If you had two packages (24 and 26), then the user should know which one they need to install. It just means that there's that much more that needs managing.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
I was thinking more of the 'pacman -Syu' case.
So, you upgrade from kernel24 to kernel26. Hmm. Normally, you would have to remember to download the new modules and upgrade.
With some sort of kernel/criteria tracking built in, then an update would ensure you have the correct versions of dependent packages. No worrying about which modules need to be upgraded for the new kernel.
Offline
Currently a kernel package is just like any other package, there's no distinction. Do you think there should be a distinction?
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
It depends if you (the developers/project managers) want pacman to become more autonomous, or leave it to the user to figure everything out.
I know Arch is made more for intermediate/expert users (one reason I chose it), but even experts wouldn't mind a bit of simplification I bet.
How special would the packages need to be? I think (at least for the simple kernel case) that the packages can remain identical, and just a bit of extra logic in pacman where the dependencies are determined. In essense, this is "dynamic dependencies".
Wait, does the current dependency system allow "or"? If so, then madwifi for 2.4 kernels depends on kernel24 or kernel24-scsi, etc. Same for 2.6. If not, then adding an or verb could solve this entire general problem elegantly.
Offline
The policy is to have no packages at all depend on the kernel packages, to allow custom kernels easily.
The packages would need to be smart enough for them to know what kernel was running. There's a lot of things, depending on exactly how you want tho solution to go.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
It seems that with two kernels, there must be a way to have dependencies with the kernel though.
What about this code in pacman:
if stock kernel package is being used
download correct module
else
run abs/makepkg
Alternatively, there could be a dependency called "custom-kernel" or something, that did the same task.
This wouldn't be backwards compatible though, so a pacman upgrade would have to occur before a new kernel/module is installed.
Offline
Define "being used". Does that mean installed? Or actually running?
What if they are only running the stock kernel for a minute and usually use a custom one?
Which package would you build using abs/makepkg? I think combining pacman (a binary package installer) with makepkg (a package builder) isn't a very good idea.
So far, all the solutions are complicated, create a need for special packages, and really take away from the simplicity of the system.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline
It is only complicated because you don't want to change anything about the current system.
We must trust that the user has a bit of sense, and can work around the obvious failure cases, like booting into a stock kernel only to download the module. However, giving some degree of autonomy to the process would allow easier upgrades as I have said before.
I only mentioned abs because it provided an easier way to handle custom kernels - you can ensure the stock kernel has whatever options are required (assuming some are needed), but not with a custom one.
If you can't have packages be dependent on the kernel package, you don't want to have a "custom kernel" dependency, and you don't want to change pacman, then the only option I see is two versions, module26 and module24, that the user chooses to sync with.
Offline
I never said I didn't want to change anything with the current system. I said I didn't mind changing it if it wasn't complicated. Making a change that depends on pacman being smart (ie. making a decision that is somewhat subjective) is a bad thing. Especially in a package manager.
I brought up this discussion mostly because I have thought about it myself and haven't come up with an acceptable solution. I wanted to know if someone else could.
It's sounding like the two version idea is the best. But with custom kernels you'd still have to pick one. At the same time it means that the package maintainer (or two) has to compile one for each kernel on every upgrade.
I have discovered that all of mans unhappiness derives from only one source, not being able to sit quietly in a room
- Blaise Pascal
Offline