Le vendredi 18 juillet 2008, Sven Joachim a écrit : > On 2008-07-18 19:59 +0200, Thomas Preud'homme wrote: > > A few minutes ago I was reading this list and discovered ctags. I > > wanted to install it and I try a apt-file ctags | grep bin which > > didn't show anything. > > > > Then I told myself maybe I already had it and tried a tab > > completion. > > > > As I did have this tools I wanted to know which package installed > > it with dpkg -S /usr/bin/ctags > > > > Here is the output : > > > > 19:55 robotux@simplet ~% LANG=en_US.UTF-8 dpkg -S /usr/bin/ctags > > dpkg: /usr/bin/ctags not found. > > zsh: exit 1 LANG=en_US.UTF-8 dpkg -S /usr/bin/ctags > > Yeah, because it's managed via the "alternatives" system. > > > *but* : > > > > 19:55 robotux@simplet ~% LANG=en_US.UTF-8 dpkg -S usr/bin/ctags > > exuberant-ctags: /usr/bin/ctags-exuberant > > > > It's related to the fact /usr/bin/ctags is a double symbolic link > > as it is an alternative. dpkg -S /usr/bin/firefox correctly answer > > iceweasel. > > > > Is it an expected behaviour because /usr/bin/ctags could be > > installed by several packages (but *has* been installed by only one > > package on a given system) ? > > It is expected because /usr/bin/ctags is not included in _any_ > package, so dpkg does not know about it. It's handled via > update-alternatives(8). > > > I prefer to ask you here before filling an useless bug report. > > This is known and the problem is: if any package contains a real file > /usr/bin/ctags, dpkg will clobber the symlink created by > update-alternatives. See http://bugs.debian.org/25759 and friends. > > Sven Yes I perfectly understand the point, but if I remove the leading / in my request dpkg -S do find the package which has installed a symlink via alternatives, as you can see with my dpkg -S usr/bin/ctags request. That part is great, because dpkg behave smoothly but so why dpkg doesn't behave exactly the same with a leading / ? Is there a reason, technical or logical ? I insist, I would perfectly understand that dpkg can't say me which package did imply a symlink to an alternative because as you said the symlink is not in the package but result of some postinst script, but as dpkg does, why doesn't he do also when the request include a leading / ? -- Why Debian : http://www.debian.org/intro/why_debian
Attachment:
signature.asc
Description: This is a digitally signed message part.