Wichert Akkerman wrote:
Previously Eric Richardson wrote:
Of course if I can't convince you then how could I convince everyone that a possible change is in order. I did think based on some of the other threads on this list about improving Debian made this a viable idea at this time. Don't take this as whining as it is not meant to be.I don't take this as whining, but at the moment I do not see the problem you are trying to solve.
I give it to you that by hand editing files such as modules.conf or the files in the /etc/modutils dir that there is no problem to solve.
But using Debian for the most part is very easy and installed packages just work thanks to dpkg/apt include kernel installs and upgrades. Installing and configuring modules is the hardest thing I have found using Linux as it requires hardware knowledge etc. The program modconf in Debian gives a nice interface to load modules and it puts the entries of modules selected into /etc/modules and puts the options to the modules (eg. options sb io=0x220 irq=5 dma=1) in the /etc/modules.conf file. So far *no* hand editing has been done and for the most part, the great advantage in this area is that the preinst, postinst scripts of the packaging do a great job of making things just work.
The problem I am trying to solve in this. Anyone using a laptop that installed or upgraded to woody that decided to update to 2.4 series kernel would have had to used the modules.conf file language to make both the 2.2 and the 2.4 kernel to work. Normally it is nice to have a backup kernel that works as you are trying to upgrade and get things working on the new kernel. The problem is that the files need to be versioned just as everything else that has to do with the kernel is. This is how you can have n different versions of the kernel on a machine and none of the software conflicts with each other except for the mentioned files. A lot of other people were confused and had problems on Debian user and debian laptop with this exact problem. In fact a really smart installer could have changed the different module names when doing the upgrade.
From a developers point of view is it easier to read a different set of configuration files or create a program that reads and interprets shell commands as the modules.conf allows? Not only that the modules.conf uses `uname -r` internally to find the correct version of the module as defaults. Explicitly having configuration files for each version of the kernel is easier and makes more sense. The installer can copy the contents of the file to the new file if desired. In reverse the package remover can remove the file. The changes needed can't be all that many and still all the old stuff works. Can't spend any more time on this solution which could make Debian easier to use but I think if you step back and see that everything else is using a filename or a directory with a version in its name then the configuration file as well should be versioned. If that is not logical then I don't know what is!
Eric