Re: mit-krb5/builtin.mk problems on solaris

[David Holland <dholland-pkgtech%netbsd.org@localhost>]

On Mon, Sep 23, 2013 at 07:35:47AM -0500, Tim Zingelman wrote:
 > I have never understood why in pkgsrc a package defines its own
 > minimum version.

The problem is that our versioning scheme isn't expressive enough, and
the cause is that old bugaboo, shared library deps.

When a library package gets an update that results in binary
incompatibility, we bump the PKGREVISION of client packages that use
it and also bump the library's minimum version, in order to be certain
that (1) client packages that depend on the new version are
distinguishable from client packages that depend on the old version,
(2) that the depends info for the new client packages doesn't accept
the old library, and (3) that the new client packages really are
compiled against the new library.

This is fine (though somewhat awkward) unless the library is a builtin
package. Then we gratuitously reject the builtin version for no reason
than that it's older than the most recent update of the pkgsrc
version.

In theory the above describes the behavior of BUILDLINK_ABI_DEPENDS,
and BUILDLINK_API_DEPENDS is supposed to fix this: in theory,
BUILDLINK_API_DEPENDS is the minimum version you must have to compile
a client package successfully, and BUILDLINK_ABI_DEPENDS is the
minimum version of the binary library package that the binary client
package needs to run successfully.

In practice this doesn't really work, for a number of reasons: first,
in order to be able to build against an older library than the latest
version in pkgsrc, if BUILDLINK_API_DEPENDS passes then
BUILDLINK_ABI_DEPENDS needs to be taken from the installed (maybe
builtin) package and not the current pkgsrc infrastructure. As far as
I know this is not done. Second, if you build against an older package
than the latest version in pkgsrc, it defeats the scheme of using
manually applied PKGREVISION bumps to distinguish client packages
built against different (incompatible) library packages. Third, often
when people update library packages with new incompatible versions,
they raise both BUILDLINK_ABI_DEPENDS and BUILDLINK_API_DEPENDS to the
current version. (I have never been clear on whether this is supposed
to be done or not.)

Fourth, there's another serious problem specific to builtin packages,
because it's possible to have both a builtin and a pkgsrc version of
the same package installed at once. Unless all client packages don't
see the same BUILDLINK_API_DEPENDS, then some client packages will
build against the builtin version and some will build against the
pkgsrc version, installing it first if necessary. Then if you ever
combine these (e.g. two client libs that depend on a maybe-builtin lib
and an app that uses both these client libs) you'll get programs
linked to two versions of the same library; if you're lucky the
consequences of this are limited to SIGSEGV. (If you never combine
such clients, there's usually no problem; but that's not always true
either, e.g. if there are executables found on $PATH.)

I don't know how to fix any of this.

-- 
David A. Holland
dholland%netbsd.org@localhost