On Mon, 7 Jul 2003, Frederick Bruckman wrote:

: > (Whenever pkgsrc might gain the ability to register *multiple* packages per
: > build a la RPM, of course, this would become a non-issue and trivial to
: > implement -- as you could produce binary packages of devel and runtime and
: > reinstall only the runtime via pkg_add on the destination system.)
:
: The devel/run-time split causes no end of problems for Red Hat users.
: A FAQ on nearly every active Open Source project these days is, "Your
: configure script says png-NNN is not installed, but it is!"

"Yeah, and?"

The issue I'm pointing out is not upgrading from pkgsrc to src/.  It's
upgrading from one pkg version to another.  Because the libstdc++ ABI
changes from major release to major release of gcc, it's useful to be able
to have the runtime libs for an older version stick around -- and even *be
installable from binaries* even if a newer version is installed.

This is where the runtime/devel split excels.  And it bites way too much in
pkgsrc:  how many times have you had to rebuild a crapload of dependencies
all at once because of a major version bump in some low-level package?
Wouldn't it have been nicer to be able to do the rebuilds in phases?

: Maybe it would be wiser to make /usr/lib/libstdc++.so.5 a symlink
: into ${PREFIX}/lib (same for libgcc_s.so.1)?

I'm a little afraid that a libstdc++ build from src/ may not be perfectly
ABI compatible with one built from pkgsrc because of compile-time autoconf
detection differences -- so this is probably *not* a good idea.  (This
happened, for instance, with openssl, where the pkgsrc version was NOT ABI
compatible with the src/ version once the src/ version was updated.)

-- 
-- Todd Vierling <tv@pobox.com>