> Now, I tried to start snx101view and it printed:
> Shared object "libgdk_imlib.so.10" not found
...
> So, the imlib dependency is satisfied, but the program actually does not
> find the library that it needs.

Yes, these open-ended dependencies cause problems. I often have same
problem when installing a library package that is newer than the package
needing it!

> Could this be fixed, please? I don't see what the dependencies are for if
> they don't guarantee that a program will run when they are satisfied. At
> least for shared libraries which are the most common reason for
> dependencies this should work.
>
> Couldn't this bye done by embedding the library version in the package
> name, like in Debian? (see
> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#NAMINGLIBPKG)

For example, I see Debian's cracklib2 version 2.7-8.5. It installs
/usr/lib/libcrack.so.2.

libmm11 1.1.3-6.1 installs /usr/lib/libmm.so.11.0.23.

libssl0.9.6 installs /usr/lib/libssl.so.0.9.6 and
/usr/lib/libcrypto.so.0.9.6.

libncurses5 installs /usr/lib/libpanel.so.5.2, /lib/libncurses.so.5.2,
/usr/lib/libform.so.5.2 and /usr/lib/libmenu.so.5.2.

Do you have any examples, because that webpage doesn't show any.

The problem with pkgsrc is that on different platforms the SONAMEs may be
different.

Does anyone have any suggestions on how a BUILDLINK_DEPENDS
(or BUILDLINK_RECOMMEND) can be dynamically set to the correct package
name?

Does anyone have any ideas on how to get the PKGNAME to dynamically add
one SONAME number to it?

But then we would still have the problem where we can't go back in time
and "make install" a package to generate the old SONAME (like you needed).
We could start having separate packages for each SONAME, but that will be
come a maintenance problem.

Improving pkg_add to correctly verify the PROVIDES versus REQUIRES before
installation is any idea. I am not sure what it can say though -- "This
package needs ..... I don't know what the package is called. Sorry."

A third idea is to have an improved pkg installation tool that uses a
database of all the metadata about all available packages. Then when a
package is to be installed, the metadata can be consulted. It needs
libfoo.1 and so it can automatically update all packages as necessary or
say there is a problem long before anything is installed. (It can also
download everything correctly and know it will work before any
extractions.)

 Jeremy C. Reed
 	  	 	 technical support & remote administration
	  	 	 http://www.pugetsoundtechnology.com/

p.s. I'll start building the metadata "available" file for the NetBSD/i386
2.0 stable packages and 1.6.2 recently uploaded.