Re: getting dpkg-shlibdeps to work on the Hurd
On Sat, May 18, 2002 at 08:51:11PM -0500, Adam Heath wrote:
> > > The one thing I can't decide upon, is when listing the matches, is if the real
> > > path of the file should be shown, or the path as stored in the dpkg database.
> >
> > [snip] interesting talk about which path to output
>
> Interesting food for thought, we shall have to keep this in mind.
I have an idea how it could be done, and it is fully backward compatible,
too.
First, if the name to search for does not start with a '/', or it does
contain globbing characters, the old search mechanism is used. Why?
Because if you have globbing characters in the name passed to dpkg, you
are probably not searching for a real file in the filesystem, but the
database of installed files anyway. Likewise for relative paths. Example:
You search for '*/README.gz' if you want to have see all packages containing
a regular file called README.gz, no matter where it is installed. So dpkg's
idea of the file location is good enough. If you look for 'doc/bash', you
will currently get all entries in the database having a .../doc/bash/...
component, so this is quite different from searching for the package
containing the file ./doc/bash (relative to the current directory), which
should only return a single result.
So, it doesn't seem to be useful to apply any other than the old search
algorithm to the above cases. Now, what about absolute path names without
globbing? Here, the current algorithm is to look for all packages with an
entry that matches the absolute path. If such a file does not exist in
dpkg's database, you get an error. Here is an example:
ulysses:/usr/share# dpkg -S /usr/lib/libz.a
zlib1g-dev: /usr/lib/libz.a
ulysses:/usr/share# dpkg -S /lib/libz.a
dpkg: /lib/libz.a not found.
Now, let's say we implement the new method for absolute file names without
globbing, and let dpkg return the name as it is in the database. Then you
would get the following output:
ulysses:/usr/share# dpkg -S /usr/lib/libz.a
zlib1g-dev: /usr/lib/libz.a # Backward compatible
ulysses:/usr/share# dpkg -S /lib/libz.a
zlib1g-dev: /usr/lib/libz.a # extension
If we would return the name as given on the command line:
ulysses:/usr/share# dpkg -S /usr/lib/libz.a
zlib1g-dev: /usr/lib/libz.a # Still backward compatible
ulysses:/usr/share# dpkg -S /lib/libz.a
zlib1g-dev: /lib/libz.a # extension
I much prefer this latter behaviour, as it lets you easily match the search
results in the "extension" case, which is what matters for dpkg-shlibdeps
and the Hurd. It seems to me if it would be implemented this way, the current
dpkg-shlibdeps package using ldd would just work on the Hurd, without
changes.
I don't have time to implement this today, but hopefully tomorrow.
This is only an analysis for the -S option. The behaviour is quite sane and
fully backwards compatible in the "files are found" case [and it will
succeed where the old dpkg -S failed to find the file]. I think this is
what is desirable for -S. Other options (maybe just for dpkg-search)
could do something more consistent (eg, either search the database, or
search for the file FOO [disabling globbing and interpretating relative
paths correctly). My code shall be written with that kept in mind
(maybe I can will just add such options, would be useful for testing
anyway).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to debian-dpkg-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: