shlib majors and the ports (Re: leaner and meaner www/firefox)

[Mikhail Teterin]

> I tested it and surprised me that package doesn't check library
> version at all.

That's right. Only the versions of the other packages are recorded
in the dependent package -- not individual versions of those packages'
libraries:

=# pkg_add ./leafpad-0.8.2.tbz
=pkg_add: warning: package 'leafpad-0.8.2' requires 'glib-2.7.4', but 'glib-2.7.5' is installed

=# leafpad
=/libexec/ld-elf.so.1: Shared object "libgobject-2.0.so.701" not found,  required by "leafpad"

=Okay, it gave the warning about what leafpad needs package for the best
=result, but why did it still installed this package? It shouldn't be
=install package at all if the library shared version has changed.

Because the shared library versions of dependencies are not recorded in
the package. At all...

We have now established, that package dependencies are not affected by
the explicit shared library versions in the LIB_DEPENDS. Woof... Moving
on to ports.

=Since, package doesn't work as I thought, then I guess my two reasons
=left of prefer to have major version in Makefile is that force users
=(keep in mind, read my later paragraph below for bump when it need) to
=update their dependencies (if they use ports tree) and easier to search
=in Makefile for bump.

This is maintainer's convenience, which should not trump that of the
user, who may not want (and should not be forced) to update all of
her/his ports at once.

="[...] a user, who already has libpng.so.4 installed, should NOT be
=forced by the abiword build to upgrade his png port."

=I believe that if the library that shouldn't bump, but it did then
=we have to hack it to make it to not bump and keep the major library
=in Makefile is a better solution. Same as how we did with gettext,
=pango and etc. The major library is there for reason. It's what my team
=(FreeBSD GNOME) is working on this change with bump when it need.

That _reason_ -- why a library's major number is there -- is to ensure
the application BINARY interface (ABI) compatibility. Building a port
from source is only affected by the application PROGRAMMING interface
(API) compatibility.

Back to the example you quoted, as long as abiword does not require
some new API-feature of png.5, it should be buildable with png.4. I
must've said this 10 times already, and am quite tired of pointing out
the difference between the concepts of ABI and API to you...

Can someone, please, take this thanksless task over? This is, after all,
a prominent member of the gnome@ team, which controls dozens of ports
(including all of mozilla software)...

	-mi