Re: getting dpkg-shlibdeps to work on the Hurd
On Sat, May 18, 2002 at 02:48:36PM -0500, Adam Heath wrote:
> On Wed, 24 Apr 2002, Marcus Brinkmann wrote:
>
> > The issue is that the Hurd has /usr linked to ., so that all libraries that
> > are usually found in /usr/lib are found in /lib, and likewise all libraries
> > usually found in /usr/X11R6/lib are found in /X11R6/lib. Because /lib is
> > always searched first (in fact, on the Hurd it is the only place searched by
> > the system, if none of the other possibilities of the ELF standard are used,
> > like rpath or LD_LIBRARY_PATH). Note that we are following the ELF standard
> > just about verbatim (I have not checked, but I don't know of any deviation).
>
> So, you remove /usr. Why leave /X11R6? Isn't it the same kind of thinking
> that made hurd decide to remove /usr?
Yes, we are working on this. Branden has some links in /lib (or /usr/lib,
don't remember) which point back to the /usr/X11R6/lib location which are in
the way. He has not responded to my inquiry if he would accepted to remove
those links for the Hurd target (that was about half a year ago, or so). I
will have to pick up this topic one more time one of these days.
> > [snip]
>
> The way I see this being done, is as follows:
>
> 1: dpkg is asked to search for a pattern in it's file database.
> 2: the pattern is split into a file pattern and dir pattern(split on '/')
> 3: a file pattern search is done.
> 4: for all matches from (3), get the realpath(3) of the file.
> 5: use the dir pattern from (1) to search this new directory list.
This will work very well. Faster than a realpath() is to do a stat()
and compare the st_dev and st_inode numbers. Both together uniquely
identify a file in the system. Of course, as with realpath, you can not
cache the values in the database, but at least it reduces the cost to one
stat for each file result. If you look for files like changelog.gz or
copyright, there will be a lot of files to compare against, but for the vast
majority of file names the number of results from (3) should be quite small.
> 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.
Mmh, I would not consider the real path, it is almost uninteresting.
I think it is harder to decide if you print the file name in the database,
or the filename as specified by the user. Let's say a user searches for
/indirect/bin/foo:
dpkg -S /indirect/bin/foo
Then I would either expect as output
foo-package: /bin/foo
or
foo-package: /indirect/bin/foo
eg, either the name as in the database, or the name I searched for. I think
it would be kinda irritating if I would get "foo-package: /mnt/bin/foo" as
the result if /bin is a link to /mnt and /indirect/bin a link to /bin.
However, as dpkg supports file globs in the search query, I am not sure that
giving the name the user searched for is an option. It is certainly not
dpkg's current behaviour. So you might have to stick with the database
path, which is not to bad. But it will force people who want to match
individual results in a multi-search query to do the same triangulation as
dpkg has to do internally, eg, for dpkg-shlibdeps:
$ dpkg -S /lib/libfoo.so.1 /lib/libbar.so.2
libfoo1: /usr/lib/libfoo.so.1
libbar2: /usr/X11R6/libbar.so.2
(this assumes that both /usr and /X11R6 are links to .).
And then dpkg-shlibdeps has somehow to match the lines to the libraries it
searched for.
Another reason to not print the realpath is that this can change.
If you have odd links in your system, and change them, you probably want to
have the same result from dpkg before and after the changes. The caller can
always look at the realpath or whatever other name for this file he wants himself.
(and, as shown above, he has to do it anyway in case a file has three
names).
> Benefits of this approach:
>
> * It allows for any kind of symlink layout for any file system.
> * Not specific to the hurd, as even normal systems(my personal one included)
> have odd symlinks, to move data to the largest mount point.
Indeed, this is an old known problem in DPKG. I think I remember discussions
about this from 1996 or 1997.
> * Much more complex search algorithm.
It's a bit more complex, but it should refactor nicely (eg, what you need in
(3) above should be possible to do with the current code, and then the
filter has to be added on top of it).
> * Much slower dpkg -S(this could be sped up with a binary database.
>
> This last downside above is actually easy to fix then one might think. In
> dpkg 1.10, there is an external search tool. All search options now cause
> dpkg to exec dpkg-search, so replacing them with something more efficient
> should be much easier.
Ah, this sounds nice, I am looking forward to it. I have to admit that
currently I am trained to just use grep on /var/lib/dpkg/info/*.list if
I need it right quick.
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: