On Thu, 2007-08-02 at 13:26 -0500, Les Mikesell wrote:
Timothy Selivanow wrote:
The LFHS is the problem here, although putting applications where you want them in the filesystem would make Linux as hard to use as the Mac. Oh wait...
That compromises one of GNU/Linux's biggest strengths, that of shared libraries. So instead of just upgrading OpenSSL, I now have to upgrade the following that is on one of my servers:
Unixes have had mechanisms to handle multiple shared library versions probably for as long as shared libraries have existed.
Yes, but like alternatives, there is a default and each time you want to deviate from the default you must specify. Even implementing a meta filesystem to store per-application environment settings is just as much work in logistics as using wrapper-scripts. Not that it couldn't be done, but your are still talking about major changes that are beyond the scope of just RPM. You are looking for a quick and easy way (i.e., no real maintenance on your part) to have multiple libraries and multiple same programs with auto-magical negotiation that the under-laying structure doesn't support.
Are you sure you want _any_ enabled repository to be able to replace your stock ssl libs, though? So far the discussion has assumed that everyone involved is operating in good faith and all problems are just accidental, but what if...?
"What if" indeed! That is one reason why I use only /my/ repo on my servers. In the past I used Karan's for a few packages, but decided to just maintain a repo for the few extra packages I need. For desktop (F7), I use (currently) only one 3rd party repo (and well-known, so hopefully not shady in nature) and I am able to see what repo the updates are coming from in yumex and yum.