On Mon, 04 May 2009 19:07:18 +0200, Raphael Hertzog <hert...@debian.org>
wrote:
On Fri, 01 May 2009, Jiří Paleček wrote:
should
almost never happen (except diversion) and the result when it happens
is
Should I read it as "the only legal situation where it returns multiple
packages are diversions (the rest are errors)" or "the majority of
situations ... are diversions", ie. does it make sense to return
multiple
packages in the absence of diversions?
dpkg -S can return multiple packages for directories too since they can
be
shared 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
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
