Subject: Re: inconsistent versions of compiled binary package found on
To: David Brownlee <abs@netbsd.org>
From: Frederick Bruckman <fredb@immanent.net>
List: tech-pkg
Date: 01/26/2002 08:36:13
On Sat, 26 Jan 2002, David Brownlee wrote:

> 	If all packages used buildlinks for the dependencies it would
> 	be possible to set a 'library nb version offset' in packages
> 	that provided shared libraries. A package including a buildlink
> 	with such an offset would add it to their 'nb' version. Every time
> 	a library was updated in an incompatible fashion the offset would
> 	be incremented.

I thought of that, too, but I don't think it's a good idea. If people
update pkgsrc incompletely, they could arrive at any particular sum more
than one way. Even if they never upload those packages, the dependencies
on their own systems will not be sane, and they will not work correctly
with downloaded packages. If, alternatively, you were to associate a
unique prime number with each "provider" package, then the products in
the "customer" packages would be guaranteed to be unique. So if gettext
has "3", libpng has "7", and so on, gnome would be
"gnome-1.4.0.2-500_billion_and_something". (I'm kidding...)

The whole problem becomes so much simpler if you only express every
dependency in the "customer" package in the Makefile itself -- no
dependencies in buildlink, no recursion in "pkg_create" or "make
install". This would make it practical to script version bumps for
"provider" packges -- first the script would build a database of
dependencies in one pass through "pkgsrc", then the script would
automatically update the dependency and ${PKG_REVISION} in every
"customer" package, and finally, it would report which files were
modified and so need to be inspected and committed.

Frederick