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 [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
