Subject: Re: buildlink3 now requires libgcrypt 1.2.0 or higher
To: Adam <>
From: Jeremy C. Reed <>
List: tech-pkg
Date: 05/27/2004 09:46:44
On Thu, 27 May 2004, Adam wrote:

> I suggest the following, every binary package should depend _at_least_
> on the version of the other one required, at the time of build.  So, if
> there
> is opencdk-0.5.4, which requires libgcrypt-any-version, and we build a
> binary
> package, the binary package should NOT depend on libgcrytp-any-version,
> but
> libgcrypt-1.2.0, which was present at the time of making opencdk.

I guess you mean force the BUILDLINK_DEPENDS to be at least the current
version. This will make many complain because in most cases it will make
repeated builds that are unnecessary.

In fact, there is a new RECOMMENDED and BUILDLINK_RECOMMENDED settings for
those who don't want to update.

Also, I am not sure how that can help when using a mix of old packages
with new packages. See my examples below.

> Aaargh, we spend too much time on this, while new packages and PRs are
> waiting. :)

In my case, I need to have usable systems. I upgraded libgcrypt and then
immediately I had a few packages broken.

Also, I upgraded gnutls and then I also had a few packages broken.

For example, my installed evolution-1.4.6 does not have any registered
dependency on gnutls nor libgcrypt. It has an open-ended dependency on

I have gtkhtml3-3.0.10 installed. It has an open-ended dependency on

I had libsoup-1.99.28 installed. It had an open-ended dependency on

I had gnutls-1.0.8 installed. It provided lib/ It had an
open-ended dependency on libgcrypt>=1.1.92.

I had libgcrypt-1.1.92 installed. It provided lib/

Because of open-ended depencencies and no checking for library versions, I
upgraded to libgcrypt-1.2.0 which provided /usr/lib/

This immediately broke gnutls and opencdk and evolution.

Because of open-ended dependencies and no checking for library versions, I
upgraded gnutls, and it also broke evolution.

According to objdump, /usr/lib/evolution/1.4/

And ldd says: => not found => not found

Packages.txt says "In some cases, the packages that depend on this new
version may need their PKGREVISIONs increased and, if they have
buildlink?.mk files, their adjusted too. This is so
binary packages will require correct versions (so a new package built
against old library won't be installed with a new library, for example)."

This idea works as long as it is followed. Maybe we should have a simple
"pkgcvslint" tool that looks at cvs diffs to see if sonames have changed.

I am not sure what the fix is with open-ended dependencies.

One idea is to have a build machine with a database of all packages
(including not installed) that, in addition to regular dependency
information, keeps track of library versions. And whenever a newly-updated
package is built, then the database can be checked to see if this new
packages uses or conflicts with the already registered library versions.

(I would also use that master database for an enhanced package installer
program so it can easily know how to install and upgrade packages because
it knows what is available and what conflicts before downloading and
extracting and before installing potentially conflicting prerequisites.)

Another idea is to have the SONAMEs used at the time of the build be
registered as dependencies. Then when attempting to have a package that is
okay with an open-ended dependency could still fail because SONAME not
available. The problem there is that the error would say a file is
missing, but can't easily suggest the package name that it would need
(because would not have been known yet for that old package). But at
least, you would not be able to install the package.

By the way, it is easy for me to notice these things because I use systems
that don't have any pkgsrc builds but just use pre-made binary packages.
Also, I often upgrade packages in place (as long as the open-ended
dependencies allow).

 Jeremy C. Reed

 	  	 	 open source, Unix, *BSD, Linux training