Context Navigation

Changes between Initial Version and Version 1 of Ticket #259, comment 3

initial	v1
1	1	Why change its name? This will require to either rebuild all apps using it or provide a forwarder. It's okay (and it's what we already do) when there is a non-backward compatible change. But simply adding a function is almost always backward compatible so there is no need to rename the dll and rebuild apps/provide forwarders. Everything will work perfectly well with the old name given that a proper version of the DLL is installed.
2	2
3		ABI changes almost always mean changing function signatures. For C++ it is done automatically in most cases. For plain C it's the author's responsibility to rename the function if it's signature changes. And if the function is renamed, the automatic dependency generator will catch it.
	3	ABI changes other than adding a completely new function almost always mean changing function signatures. For C++ it is done automatically in most cases. For plain C it's the author's responsibility to rename the function if it's signature changes. And if the function is renamed, the automatic dependency generator will catch it.
4	4
5	5	Regarding the dependency tree. While I think that RPMDB is capable of handling thousands of dependencies, I agree that C++ imposes some problems (I already wrote about that). But given that the OS/2 kernel itself feels pretty much ok with them, I guess RPM will also do. And as a last resort, If we are not satisfied with real-life tests, we may simply disable this generator for C++ symbols.