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
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) ?
I prefer to ask you here before filling an useless bug report.
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
07-18-2008, 06:04 PM
Sven Joachim
Bug or normal behaviour with dpkg -S ?
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
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
07-18-2008, 11:18 PM
Thomas Preud'homme
Bug or normal behaviour with dpkg -S ?
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 / ?
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,
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
> > ~$ 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
...
> > 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.
Why you say "it doesn't work here"? It is alternative so following
should be shown as expected.
$ dpkg -S bin/editor
dpkg: *bin/editor* not found.
This is corect response per manual: dpkg-query(1). "This command will
not list extra files created by maintainer scripts, nor will it list
alternatives."
> 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 ?
They use the same method. But each package comes with different
combination of names.
When you run
~$ dpkg -S usr/bin/ctags
it does substring match with "usr/bin/ctags" as I said which happens to
pick up one of the installed package /usr/bin/ctags-exuberant (and this
happen to be alternative but any substring matched installed file name
could be picked).
What you are doing here has nothing to do with alternative. No symlinks
created by alternative system is printed out by dpkg -S.
...
> > 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
...
> > is what I do to find such.
Just to fill gap: I find that /var/lib/dpkg/alternatives/ctags has
/usr/bin/ctags alternative defined via this acton.
For actual alternative setting, you nee to look into:
/var/lib/dpkg/alternatives/editor
/var/lib/dpkg/alternatives/ctags
Each file define alternative setting. That is how you find alternative.
Please read dpkg-query(1) manpage and update-alternatives(8) manpage.
Osamu
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
07-21-2008, 09:19 AM
Thomas Preud'homme
Bug or normal behaviour with dpkg -S ?
Le dimanche 20 juillet 2008, Osamu Aoki a écrit*:
> Hi,
>
> > > ~$ 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
>
> ...
>
> > > 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.
>
> Why you say "it doesn't work here"? It is alternative so following
> should be shown as expected.
>
> $ dpkg -S bin/editor
> dpkg: *bin/editor* not found.
>
> This is corect response per manual: dpkg-query(1). "This command
> will not list extra files created by maintainer scripts, nor will it
> list alternatives."
Yep I understand. That was what I tried to say with "it doesn't work
here". I should have wrote "It doesn't work here as expected according
to the manual of dpkg".
>
> > 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 ?
>
> They use the same method. But each package comes with different
> combination of names.
>
> When you run
> ~$ dpkg -S usr/bin/ctags
> it does substring match with "usr/bin/ctags" as I said which happens
> to pick up one of the installed package /usr/bin/ctags-exuberant (and
> this happen to be alternative but any substring matched installed
> file name could be picked).
Ok, you mean dpkg -S usr/bin/ctags will match *usr/bin/ctags* or
something like that. Effectively it's all logical. I don't think enough
sometimes.
>
> What you are doing here has nothing to do with alternative. No
> symlinks created by alternative system is printed out by dpkg -S.
Yeah I did understand, don't worry but I didn't think about how dpkg -S
match the query with the result.
>
> ...
>
> > > 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
>
> ...
>
> > > is what I do to find such.
>
> Just to fill gap: I find that /var/lib/dpkg/alternatives/ctags has
> /usr/bin/ctags alternative defined via this acton.
>
> For actual alternative setting, you nee to look into:
> /var/lib/dpkg/alternatives/editor
> /var/lib/dpkg/alternatives/ctags
>
> Each file define alternative setting. That is how you find
> alternative.
>
> Please read dpkg-query(1) manpage and update-alternatives(8) manpage.
Ok, I'll know it for my next search into alternatives. Without this
information I would have searched in /etc/alternatives or an
update-alternatives command.
Bug or normal behaviour with dpkg -S ?
