On Mon, Jan 24, 2005 at 10:02:52AM -0500, Jeff Spaleta wrote: > On Mon, 24 Jan 2005 09:15:14 -0500, Sean Middleditch > <elanthis@xxxxxxxxxxxxxxx> wrote: > > We _have_ had this problem, btw. The problem is that it's not generally > > developers that notice it. It's the user that just want to have their > > machine work. I go to install third party app Foo from Foo's web site, > > it needs libbar.so.2, Fedora only has libbar.so.1, and many other apps > > on the net require libbar.so.1. > > A third part website is packaging libbar.so.2 in a package of the > same package name as Feodora's libbar.so.1? Why would a third party > site do that? Unless the intention was to replace the Fedora package? > Isn't this an example of the care 3rd party packagers should be taking > to make sure their packages work well with Core? I would reverse the setup: Shouldn't the core distribution have scheme to allow for doing so without blowing away half of the system? After all sonames were "invented" upstream to allow coexistence of libraries of different sonames, so having the soname-in-rpmname scheme follows this philosophy and allows 3rd party packagers (and the vendor itself) to have clean ways of updating/coinstalling a new library. The current solutions are too hackish to be even considered a natural approach. Look at gcc34 and the required obsoletes in gcc to deal with this cruft. A proper scheme of coexisting packages for certain classes (libraries, compilers, interpreters) layed out once and for all will bring piece here forever ;) -- Axel.Thimm at ATrpms.net
Attachment:
pgpcA0ZpdWItd.pgp
Description: PGP signature
