Subject: Re: dependency on gcc3-c++ and gcc3-c too strict
To: Todd Vierling <>
From: Jeremy C. Reed <>
List: tech-pkg
Date: 02/10/2005 18:53:30
On Thu, 10 Feb 2005, Todd Vierling wrote:

> > I believe that gcc-c and gcc3-c++ libraries from 3.3.4 are good enough to
> > work with packages built with 3.3.5.
> But is this something we really want to encourage?  The general assumption
> should be that, at runtime, you have libs at least as new as the build-time
> dependency.

I don't know if it should be -- and pkgsrc doesn't force anything like
that now. (If we did then @pkgdep would become like @blddep but instead of
being a specific version it would be a >= range.)

If it works, it works.

For probably over a year, I have been using a binary packages on systems
that do not have any pkgsrc building. I pull over the new binary packages
and install them. I don't install the dependencies to latest versions
unless it is specifically forced. (I use my custom pkg_add -r or -u to
replace packages in place as needed.) Very frequently I have binary
packages using dependencies older than what they were built with (simply
because the @pkgdep allow it).

This has seemed to work fine. And it makes it fast for reinstalling

Usually the only problem (now rare) I have is when someone (including me
:) forgets to bump a BUILDLINK_RECOMMENDED when the shared library names

> That said, this dependency could be switched to bl3 files using
> BUILDLINK_DEPENDS and BUILDLINK_RECOMMENDED with all the usual connotations
> of that.

I was thinking about that and it seems to be a fine way.

I guess it won't hurt for me to update gcc on my non-pkgsrc box and the
open-ended gcc3-c++>=3.3.4 will allow it to work. I was just wondering if
that was required since I saw the PROVIDES= and REQUIRES= indicate that it
is not required.

 Jeremy C. Reed

 	  	 	 open source, Unix, *BSD, Linux training