coapp-developers team mailing list archive

[Philip Allison <mangobrain@xxxxxxxxxxxxxx>]

On 14 April 2010 15:17, Garrett Serack <garretts@xxxxxxxxxxxxx> 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