On Thu, 2009-03-19 at 23:09 +0100, Frans Pop wrote: > On Thursday 19 March 2009, Jon Masters wrote: > > Yes, it was a bad idea of > > mine (perhaps) to change the existing file format and I've learned > > something, but it should only have affected for example that 3.4 > > release you're using. > > Do you mean that earlier versions are not affected? Hasn't depmod > generated full paths basically any version up to 3.6? Yes, it was 3.6 where it changed, not 3.4. However, there was a backward compatibility issue during development that I was referring to. That isn't the problem here anyway. The "problem" is that you want to use a newly generated .dep file on an old install. I know that would be nice, and I'm sorry that it bothers you, but at the same time you don't expect newly built binaries to run against an older version of glibc they weren't built against, etc. > But even if it is only 3.4, that still makes it every Debian stable user > (and unknown other distros) who runs the risk of ending up with an > unbootable system for hard to trace reasons... No, it really doesn't. If you upgrade to a new module-init-tools and run depmod, then everything works. If you use the old .dep files then it still works. If you force downgrade and don't rebuild your .dep files then there certainly is the risk of being out of sync - but there are other times where such things can happen too. I'm sure other utilities have similar. > Potentially painful for example for NAS devices where the kernel and > initrd get installed in flash, replacing the previous version. Yes, and in that case there's no problem. If you do a forward upgrade everything works just fine. It's only if you try to mix versions and go backwards that you get a problem. I can see this in a cross-build setup being a slight annoyance, but even there most people would use the same version of the tools or expect to have problems building on a newer box for an older release. > As the kernel Makefile does run depmod during a build, I don't think it's > strange to assume users rely on that modules.dep being valid, even for > older versions of modprobe. It works fine as long as your box is self-consistent. What is the actual problem other than that mixing versions and trying to go backward without quickly re-running depmod might cause module load problems? > What exactly are the resons behind the change in file format that're so > strong that depmod cannot continue to generate the old format for the > next 5 years or so as a transition period I guess it's called progress ;) Sarcasm aside, if you can give me an example of an actual real life set of users who are adversely affected then I'll try to do something to help out. But if you're asking for old versions of software to be compatible with newer releases in every case I think you're not being terribly realistic. The kernel changes to make progress, and so do other utilities. Jon. -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
