[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug or normal behaviour with dpkg -S ?



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


> 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.

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


Reply to: