On 14 April 2010 15:17, Garrett Serack <[email protected]> wrote: > WinSXS allows a publisher of a shared library to set the policy of the shared > library so that if they put in a bug fix, but do alter the binary interface > (ABI) then at run time, the application picks up the latest ("Most > recommended") *binary compatible* version of the library. > > This means that you bind Python to OpenSSL 0.98h. A bug is found, the > publisher of OpenSSL releases 0.98k, and since the ABI hasn't changed, the > major & minor versions haven't changed [0][98], just the revision [k]. So > once the new library is installed, Python will use it. > > *This is the behavior we want*
Yes, it is. Any other behaviour is counter-productive, and defeats the purpose of CoApp, in the sense of the time and effort being put in to make Windows apps benefit from a decent shared library system. > So, if you really really really need to bind to a very specific version, and > you are dead set against preserving the shared library model, while it is > possible to force bind dynamically to a specific version, what you are really > wanting is to be statically bound. Also true. If you're going to pick a specific version and stick with it, regardless of security and other bug fixes, you might as well copy and paste the library source directly into the application - it is not how libraries are supposed to be used. Requiring specific versions forces end users to have multiple versions of a shared library installed, it stops the applications with such requirements from benefiting from work on the library, and is just a stone's throw away from the even-more-evil practice of dependency bundling (in which the source of a library really is treated as if it was part of the application itself, often rewriting the library's original build scripts in the process). Remember, if your project is open source, then that source is your end product just as much as the binaries. That source is no good to anybody else if they can't build it, which is exactly what so many developers used to *nix find difficult on Windows, and exactly what something like CoApp is a good opportunity to address. Any time a developer thinks their project just won't work if their build process stays within the bounds of best practices needs to stop and think about whether they really understand those practices, and about the repercussions of ignoring them. >>> If we move towards building, signing and distributing projects on behalf >>> of their owners, perhaps one of our pre-requisites would be that the project >>> needs to elicit the exact version of their dependencies that they did all >>> their release testing/development against. > > Thoughts? A bug in a shared library ought to represent a (potential) bug in any apps which use it: if it can be fixed without breaking ABI, it should be, and no consumers of that library should think twice about upgrading. If the bugfix breaks the app, the app may have been using the library in the wrong way (hence, a bug in the app). If the bugfix introduces other problems, through the law of unintended consequences, that is something which should be picked up in testing of the library as it probably breaks more than one consumer of the library. There are many examples of dealing with these issues dotted throughout the history of various Linux distributions - it can sometimes be an art as much as a science, but it isn't completely intractable. Just because a new version of something exists, package managers don't have to immediately bump their packages, and admins don't have to immediately download and deploy new packages in production. Intentionally sticking with out-dated libraries is a poor substitute for testing. Regards, Phil _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
