On Tue, 17 Jun 2003, Jeremy C. Reed wrote:

> On Tue, 17 Jun 2003, Todd Vierling wrote:
>
> > If the needed libraries aren't on the destination system, what guarantee do
> > you have that pulling in a pkgsrc-compiled version (for your FORCE_DEPENDS
> > proposal) is in any way ABI compatible with the base-system version found on
> > the build box?
>
> I don't see how that would happen.
>
> With the option defined, not only would it force the DEPENDS but it would
> build that dependency and use it. (So if the build system had an openssl
> in base system, then it would now get two installs of the openssl and the
> software would use the LOCALBASE version by building with buildlink2.)

And if the two happen to have the same soname? You lose! On NetBSD,
at least, if the required shared library is found in the default path,
the RPATH isn't even consulted. I'd bet it's the same on Linux.

> > The base OS used for building a release must be *no newer* and have *no
> > additional base system libraries* than any machine on which you plan to
> > install a binary package.  This is common sense when building binaries of
> > any kind, not just from pkgsrc.

That's the bottom line. There has to be a common base you can count on.

> I don't think that matters. If the build system is newer and it creates
> newer versions of the packages and registers all the dependencies using
> my FORCE_DEPENDS option, when you try to install on older system, it will
> complain saying older version is installed.
>
> (Yes, I can imagine if the dependency checks were open ended then if a way
> newer version of a dependency is installed and it accepts it, there may be
> problems, but that is probably because the original package DEPENDS were
> open-ended.)
>
> Please note that I have been using this idea off and on for about six
> months. I have build many packages under various Linux systems and reused
> on other Linux systems (without making sure one was older or newer).

You got lucky. You're begging for coredumps, instabilities, and
corruption of data.

Frederick