Subject: Re: pkg/35012: pkgsrc binary package dependancy system is broken
To: None <pkg-manager@netbsd.org, gnats-admin@netbsd.org,>
From: Jeremy C. Reed <reed@reedmedia.net>
List: pkgsrc-bugs
Date: 11/08/2006 03:05:06
The following reply was made to PR pkg/35012; it has been noted by GNATS.

From: "Jeremy C. Reed" <reed@reedmedia.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/35012: pkgsrc binary package dependancy system is broken
Date: Tue, 7 Nov 2006 20:58:57 -0600 (CST)

 On Wed, 8 Nov 2006, kre@munnari.OZ.AU wrote:
 
 > >Fix:
 > 	When a binary package is built, the dependencies (for at least
 > 	libraries, and anything else that influences the compilation
 > 	process - anything that provides C .g files, or their equivalents
 > 	in other languages) MUST be (at least) the versions that were
 > 	installed when the binary package was built - later versions
 > 	are generally OK (most library developers attempt to keep backwards
 > 	binary compatability - not all of them, but most - even more than
 > 	backwards source compatability).
 >
 > 	In this case, that would have told me that I needed
 > 		gtk2+>=2.10.6
 > 	(etc) and then i would have known that I needed to upgrade
 > 	gtk2+ before firefox2 could be installed (which most likely
 > 	would have meant upgrading a bunch of other stuff as well).
 > 
 > 	Note: this cannot (should not, or even must not) be fixed with
 > 	the dependencies in the source versions of the packages.
 > 	If firefox2 says that gtk2+ version 2.8.17nb1 or better is
 > 	OK to use to compile against, then that's all that should be
 > 	required - that is, if I compiled firefox2 on the system
 > 	I installed it on, upgrading nothing, I'd expect it to work.
 > 	(If that's not true, then there's a bug in the firefox2
 > 	dependency list, but that would, if it happened to be true,
 > 	be a comparatively trivial issue - and I have no reason at all
 > 	to assume that anything like that is a problem).
 
 For a couple years on a couple systems I have used binary only packages 
 (with no pkgsrc tree and no builds). I very often have had packages built 
 with newer dependencies on the build system be used on system with older 
 dependencies.
 
 The BUILDLINK_API_DEPENDS.${foo} and BUILDLINK_ABI_DEPENDS.${foo} 
 variables usually work good for this. (They used to have different 
 variable names last year and before).
 
 But, we do have open-ended dependencies that sometimes cause problems.
 
 The packages can also record the specific library so names needed 
 (REQUIRES in +BUILD_INFO) and what libraries provided (PROVIDES). If we 
 had a tool to take advantage of that, it would be good.
 
 As for changing the dependencies to be start from the version used to 
 build against, that sounds like an okay idea.
 
 Some have advocated just always using the exact version.
 
 Either way, that info is recorded also. Here is an example with lyx-qt I 
 built today:
 @blddep aspell-0.60.4nb2
 @pkgdep aspell>=0.50.3
 
 So maybe you are suggesting that @blddep should be forced as at least the 
 minimum.
 
 Also I wonder in your case if there is a problem with the 
 BUILDLINK_ABI_DEPENDS?
 
 - Jeremy C. Reed