On Sun, 19 May 2002, Martin J. Laubach wrote:

>   However, the issue we are talking about here is "I want to update
> some leaf package (no other packages depend on it), but due to
> buildlink magic it forces me to upgrade all packages it depends on
> to the most recent version".
>
>   So while I can understand that if I touch, for example, libpng,
> everything needs to be rebuild, it's absolutely ridiculous to have
> to rebuild half of your packages because you upgrade, let's say,
> gnucash.

Before we criticize the buildlink auto-bumps too severely, please
recall why they were put there in the first place. Many GNU configure
packages will build differently depending on features found or not
found in the packages they require. That is, it may roll it's own
functions to make up for something missing in an older version of a
shared library, or more likely, it'll enable some new feature, but
make it conditional on the that feature being present in the available
interfaces.

That's all very nice, but the philosophy doesn't get along well with
package wildcards in *binary* packages as they're currently
implemented, which are identically the same wildcards that apply at
build-time. So while it may be true that gnucash will build and run
against pth-1.3.2, gtk+-1.2.8, and gdk-pixbuf-0.11, it's extremely
unlikely that, if built against pth-1.4, gtk+-1.2.10, and
gdd-pixbuf-1.17, it will still run against the older set of
requirements. Just try it sometime. The first obstacle is usually the
-rpath-link dependencies, which (sometimes) spare you from firing up,
but then dumping core or corrupting data.

So the idea was, you just bump the BUIDLINK_DEPENDS in the
buildlink.mk file whenever an interface is added (that is, the minor
version is bumped), and there's no possibility to go wrong there.
Unfortunately...

1) It's not enough. If you bump a dependency of a package that has
dependencies (or a package that could have dependencies in the future,
in other words, any package), you need to bump it's version, too, so
that you can properly describe the requirement in the mutual
dependent. Failure to do this leads to an unusable collection of
binary packages, and that's a historical fact. Essentially, this
requirement defeats much of the purpose of BUILDLINK_DEPENDS, which
was to spare the developer from having to change lots and lots of
files after an update to a package with lots and lots of dependents,
but them's the breaks.

2) It's not happening. E.g, with "pth", the BUILDLINK_DEPENDS bump was
overlooked with the last few (minor bump) updates. If you try to build
"galeon" against pth-1.3.2 and gtk+-1.2.8, you lose.

>   After the original post here I thought up some mechanism how
> not to get this "update ripple effect" -- then I checked bsd.buildlink.mk
> only to find that _exactly_ what I had in mind is already implemented.
> It's just not used anywhere. Perhaps jlam as the author has some
> insight?

It's not true that it's not used *anywhere*. I predict it'll never be
commonly used, because it's fairly difficult for the developer to
demonstrate that some package built against one set of dependencies
will actually work properly when run against an older set.

>   I'm not sure why it's not used, that's what this thread is all about.
> I feel that packages should state exactly which version of other
> packages they depend on -- and not rely on buildlink's mechanism
> of requiring whatever happens to currently be in pkgsrc.

I'd like to see everything out in the open, too, but I don't see that
happening. One light at the end of the tunnel -- packages packaged
with current pkgsrc now contain "@blddep" fields listing the packages
they were actually built against. This holds out the possibility of a
tool that could be run over a collection of binary packages to enforce
a more strict discipline than that implied by the build-time
dependencies.

Frederick