On Fri, 01 May 2009, Jiří Paleček wrote:shouldalmost never happen (except diversion) and the result when it happens isShould I read it as "the only legal situation where it returns multiple packages are diversions (the rest are errors)" or "the majority ofsituations ... are diversions", ie. does it make sense to return multiplepackages in the absence of diversions?dpkg -S can return multiple packages for directories too since they can beshared by many packages but in the case of real files AFAIK it can only happen with diversions.
Ok. Thanks.
Yes, but I think this is unattainable. Especially when doing transitions,you're not likely to have both packages in sync.I don't see why it would be so difficult. Diverting a file means that you have a drop-in replacement and I don't see why you couldn't provide dependencies that are compatible (even if not exactly the same).
Yes, you can make it compatible (although I'm not sure what exactly you mean by "compatible"). Or maybe even the same, but when things change, it has to be maintained, which doesn't happen automatically.
I just wanted to know if it would be OK for dpkg-shlibdeps to use only one package for a library (eg. in case of diversions, use dpkg-divert to find the right one) and fail in case of ambiguity.What is the right one, the non-diverted one ?
I'd say so. If the purpose of dpkg-shlibs is to translate shared object dependencies as viewed by ld.so into package dependencies for dpkg, it seems to me the correct package(s) to depend on is the one that provides the binary that was used for the build (let's put aside the situations when no package contains the library used, eg. it was provided by the user who overwrote the file from the package).
Regards
Jiri Palecek