No subject

- need to have proven field usability( the thing never crash)
- need to try new version.
This produce a conflict, that is
- slow down development because new library or application
  are not tested/exercise by end users.

With the RedHat proposition, I can ask you to try a different
version to pin point a problem.

With the RedHat proposition, application developper have more
liberty to work with library version they fell more confortable with.

perverse exemple:
I have
/lib/libssl.so.0.9.6	openssl096
/lib/libssl.so.0.9.6b	openssl096b
/lib/libssl.so.0.9.6c	openssl

We can, with the scheme of having dependency on library, upgrade
to a new openssl package that have /lib/libssl.so.0.9.6d

What can append and does append, is that some applications
may still require /lib/libssl.so.0.9.6c

With run time link on /lib/libssl.so.0, application already
functional with /lib/libssl.so.0.9.6c may now be in trouble
with the new library.

That is to say, dependency based on package will have the
following features.  Upgrade of package library will force
necessary upgade of all packages requiring this library.

The rpmfind.net site with searching for /lib/libssl.so.0.9.6b
will give you the package for your distribution

>     On Debian, it's all just magickal, and it works. Try upgrading gnucash
> without apt. Have fun.
> 
>     Mike