Hello,

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

actually /usr/lib/libcrack.so.2.7 (/usr/lib/libcrack.so.2 is just a
symlink). The SONAME is libcrack.so.2

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

the SONAME is libmm.so.11

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

the SONAME is libssl.so.0.9.6 and 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.

SONAMEs are libpanel.so.5 , libncurses.so.5 , libform.so.5 and libmenu.so.5

So, the name of the package always embeds the version number from the
SONAME at the end. 

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

I don't understand what are you saying... the examples you just gave are
not enough?

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

Ah, damn.

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

I wouldn't have this problem. pkg_add would tell me that I didn't have the
imlib10 package that is needed, and either I would go and search for it
(and find it, because it will be part of the same bulk build package
archive that I downloaded snx101util from). Or a smart conflict/dependency
resolution tool like apt-get would do it for me.

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

Ah, I see that the library names are recorded as REQUIRES. But maybe they
should be without full absolute paths?

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

Yes, something like apt-get or various frontends like aptitude...

Most of Linux distributions seem to have a "dumb" package installer which
can just install a package from a file and record it as installed (and
deinstall it, too), like dpkg and rpm, and a "smart" conflict and
dependency resolution system like apt-get or yum (which call the former).
This seems like a good policy because you can experiment with different
dependency resolution tools.

Bye	Pavel