Frederick Bruckman wrote:

> package are not bounded on the top -- bumping all the versions in step
> neatly addresses that, too, because the user can then use "lintpkgsrc
> -i" to identify all the packages that need to be upgraded.

  The problem I see here is the reverse direction.  It's awkward enough
to bump all the version numbers of all packages that (directly or
indirectly) depend on png (and you'd definitely have to do that if you
want to avoid any slips).  Ony my system, this would be 88 packages, but
in the package tree, I'm sure this would be a lot more.

  What's worse, we'd have to make sure, these new packages only build
against the newest png, otherwise we could again end up with binary
packages linked against an old version of png.  The problem I am having
here is that we force users to upgrade png even if they only want to
perform a minor update at the end of that chain.  E.g., if I wanted to
update pan, which would have worked just fine with the older version of
png I have installed, I suddenly have to update png and an additional 88
packages on my system that also would have worked just fine with the old
png.

  My concern here is that we are trying to solve one problem by creating
another wone :-(

  Cheers
      ,
   Rene