Hi Rod, Thanks for the detailed response.
Of course I agree that it's better to avoid the problem by carefully controlling public interface changes. However more and more software in Solaris comes from external sources and while we can work with community maintainers and try and make sure they follow similar standards, ultimately it's their call. This is the point where some people would say that it's our (Sun's) call whether we update their packages in Solaris or stick to the previous version and apply our own bug fixes as needed, but that's wrong. Because of the complex network of dependencies, we are often required to update otherwise we can't build some other package. And neither can our customers. So we can't break the interfaces we'd shipped but we can't not update either. My favourite example is libxml2. Critical parts of ON depend on it, so it was declared Standard. However GNOME requires the latest and greatest. So, if there's an ABI breakage [happened before] that would break ON, we can't update. Not being able to ship GNOME on Solaris is also not an option. So what can we do? Ship a private copy of libxml2 with GNOME. Blastwave will have to do the same. And others too... What I'm getting at is, if you don't want to update and don't want to duplicate, you'll end up with even more duplicates, and in an ad-hoc manner. So I still think that well controlled and documented duplication is this the only way in these cases. I'm not taking about duplicating every single open source library, only the ones we are not allowed to break and only when the community maintainer breaks it and refuses to fix it. How to do this, or whether it's possible to do it correctly is another question. I don't know enough about this topic to make any suggestions. Thanks, Laca On Sat, 2005-07-23 at 12:56, Rod Evans wrote: > 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? :-) _______________________________________________ opensolaris-discuss mailing list [email protected]
