Le samedi 19 juillet 2008, Osamu Aoki a écrit : > On Sat, Jul 19, 2008 at 01:18:48AM +0200, Thomas Preud'homme wrote: > > 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 ? > > Yes: > > ~$ dpkg -S usr/bin/ctags > exuberant-ctags: /usr/bin/ctags-exuberant > ~$ dpkg -S /usr/bin/ctags > dpkg: /usr/bin/ctags not found. > ~$ dpkg -S '/usr/bin/ctags*' > exuberant-ctags: /usr/bin/ctags-exuberant > > See man dpkg-query: > Normal shell wildchars are allowed in package-name-pattern. Please > note you will probably have to quote package-name-pattern to prevent > the shell from performing filename expansion. For example this will > list all package names starting with “libc6” > ... > -S, --search filename-search-pattern... > Search for a filename from installed packages. All standard > shell wildchars can be used in the pattern. This command will not > list extra files created by maintainer scripts, nor will it list > alternatives. > > Tricky part is when started with "/" it uses full exact match while > without leading "/" it uses partial text match while Yes, thanks for you lights. It's perfectly clear for me now. > > > 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 / ? > > The behavior change with leading "/" is different issue from > alternative symlinks. It was just sheer luck of matching string > which picked /usr/bin/ctags-exuberant. Indeed. To convince myself I did the search with usr/bin/editor and effectively, it doesn't work here, according to manual. The last point I don't understand is why it do work with ctags which is an alternative. Is the packaging of this alternative (and firefox) different from those of editor alternative ? > > If search needs to check alternatives system data, it is much slower > and complicated. > > If you think searching alternatives is important, I guess you need to > write tool for it. For installed packges, > > /var/lib/dpkg/alternatives$ grep ctags * > ctags:/usr/bin/ctags > ctags:ctags.1.gz > ctags:/usr/share/man/man1/ctags.1.gz > ctags:/usr/bin/ctags-exuberant > ctags:/usr/share/man/man1/ctags-exuberant.1.gz > etags:/usr/bin/ctags-exuberant > etags:/usr/share/man/man1/ctags-exuberant.1.gz > > is what I do to find such. > > Osamu Thank you very much Osamu. Reguards -- Why Debian : http://www.debian.org/intro/why_debian
Attachment:
signature.asc
Description: This is a digitally signed message part.