Laca wrote:
As far as I understand, the main problem with multiple versions (apart from the increased maintenance effort) is that different versions of the same lib may end up linked to the same executable (through dependent libs) and it'll cause unpredictable runtime linking and most likely a crash.
There are a number of issues with multiple versions. The user if often left to discover that multiple versions exist, and then asks what's the difference, or more importantly, which one am I supposed to use. They you have to locate the version you need. And then comes the issue of what happens when multiple versions get loaded in the same process. There can be a larger maintenance/decision-making process for the user than there is for the maintainer of the multiple versions.
It's a long shot, but would it be possible to enhance the linker/runtime linker to have some sort of namespacing that would enable it to work correctly with multiple versions?
We've considered this path a couple of times, but keep returning to the same questions. If you had multiple versions how do you tell someone which one to use? Sadly many developers of shared objects don't even establish the dependencies they need. They make reference to "foo()" and expect it to materialize at runtime (typically because of the dependencies established by the application itself). What version of "foo" does the shared object get in this case? And how do we find alternative libraries? $ORIGIN helps, but we still live in a world dominated by wrapper scripts and LD_LIBRARY_PATH settings. An observation is that most users don't know of multiple versions of a library until their app breaks. Breakage which can be subtle and very hard to debug. Then we can give them the tools and information to build against differing versions. But this occurs after the upheaval of the breakage. This doesn't make happy users. Although developers exist who could manage multiple versions, I think most of our developers (the big customers - the ones that make all the noise when something breaks :-) don't want to know. They build apps from multiple, asynchronously delivered components, and don't have a clue what depends on what. They want to call "foo", they want us to find it, and they expect "foo" to continue working as it always has. So, with these issues, we've focused our energies on maintaining single instance, compatible objects. This isn't easy, which accounts for some of our review processes. It puts the burden on the library developer, rather than back on the user - as it is a burden to the customer to decide what versions to use. We've tried hard to define our public interfaces, we don't allow them to change, we minimize exporting data, etc. etc. Lots of tricks to try and insure an object doesn't change but can still evolve in a compatible manner. We haven't always got it right either, and the desire to evolve a library in some manner has been hindered by the compatibility requirement. We do have some tricks up our sleeves. You can isolate objects into groups, use direct bindings, etc. You can use these techniques in specialized ways to work with multiple interfaces. But again, my observation has been that these are employed after an application has broke, and many hours have been spent unraveling why. So, I don't want to imply that other versioning schemes might not be useful, but our focus has been on staying away from "dll hell", and thus not having the user need the techniques in the first place. Keep it simple.
This way we could have 2 versions of those libraries where interface stability suffers: one kept stable (bugfixes and compatible changes only) for those who want their code to work forever and one closely tracking the latest community code for those who need the latest and greatest and don't mind rebuilding.
Do you think that if a simple versioning scheme existed that you'd only have 2 versions? :-) -- Rod _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
