FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 07-18-2008, 05:59 PM
"Thomas Preud'homme"
 
Default Bug or normal behaviour with dpkg -S ?

Hi there,

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

*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) ?

I prefer to ask you here before filling an useless bug report.

Reguards

--
Thomas Preud'homme

Why debian : http://www.debian.org/intro/why_debian


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-18-2008, 06:04 PM
Sven Joachim
 
Default 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
 
Old 07-18-2008, 11:18 PM
Thomas Preud'homme
 
Default 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 / ?

--
Why Debian : http://www.debian.org/intro/why_debian
 
Old 07-19-2008, 02:05 AM
Osamu Aoki
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-19-2008, 12:03 PM
Thomas Preud'homme
 
Default Bug or normal behaviour with dpkg -S ?

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
 
Old 07-20-2008, 03:47 AM
Osamu Aoki
 
Default Bug or normal behaviour with dpkg -S ?

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

> 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
 
Old 07-21-2008, 09:19 AM
Thomas Preud'homme
 
Default 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.

>
> Osamu

Thomas Preud'homme



--
Why Debian : http://www.debian.org/intro/why_debian
 

Thread Tools




All times are GMT. The time now is 11:42 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org