On Mon, Jun 22, 2009 at 02:41:09PM +0200, Christian Holm Christensen wrote: > > I understand this issue, but putting libMatrix in /usr/lib/root avoid file > > conflict with other package, do not address the problem of library name > > conflict at run-time.
> Agreed. Suppose you have packages bar and baz, both of which contain > /usr/lib/libfoo.so.1. If bar "Conflict"s with baz or vice versa, then > both of them cannot be installed at the same time, and there will only > be one possible /usr/lib/libfoo.so.1 on the system. Now suppose the > package gnus comes along, which also provides /usr/lib/libfoo.so.1, then > both bar and baz needs to "Conflict" with gnus, or gnus has to conflict > with bar and baz. I guess it is an N! problem. If all of these libfoo.so.1 files implement the same interface, why does someone ever need to have more than one of them installed at a time? In that case, Conflicts: is reasonable; and you can use a mutually agreed-upon virtual package (Conflicts/Replaces/Provides) to solve the N! problem. If they don't implement the same interface, then why are they using the same name? In this case they should solve the conflicts by using distinguished sonames, not merely different paths for the library, to avoid accidental library path collisions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
