[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#518412: linux-2.6 install errors due to incompatible depmod files [was Re: Bug#518412: initramfs-tools: must support relative paths in modules.dep ]



On Thu, 2009-03-19 at 23:58 +0100, Frans Pop wrote:

> > 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.

> Sure, if there are very strong reasons to break things, fine. But whenever 
> possible the kernel has ensured backwards compatibility, mostly only 
> _after_ someone "complained". Think of the i386 and x86_64 symlinks after 
> the x86 integration, think of the COMPAT_SYSFS flags, think of optional 
> support for old /proc files, think feature-removal-schedule.txt.

All of these examples refer to the future. The *future*. Things that
will change, preserving backward compatibility, keeping symlinks around
for those who are used to the old location. *Backward* compatibility.
But the issue you raised was about *Forward* compatibility. This is nice
but isn't the same. That would be like guaranteeing that all future
kernel features will work with a kernel from 6 months ago, or that
modules will, or other similar stuff.

> So far you seem to be avoiding to give the reasons for the change. What 
> would be so wrong with ensuring the compatibility for some transition 
> period and avoiding the problem?

There is compatibility. From the past, to the present, into the future.
But you want to use *future* generated files with a *past* version. That
is not backward compatibility and it is not the kind of thing where you
can "preserve for 5 years", etc. How does the old version know something
is going to change? It doesn't and it can't. v3.4 will always be the
same, and it won't change. The files changed slightly in v3.6, but v3.4
can never know about that.

> P.S. Thanks a lot for your prompt replies. I do appreciate the discussion.

Sure. Hopefully you see that this is not a regular compatibility issue.

Jon.





Reply to: