On Fri, 25 May 2001, Dr. Rene Hexel wrote:

> 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.

>   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.

That's already been done, actually, with the DEPENDS bump. At least,
for the ordinary way, of doing "pkg_delete -r png" and then
re-building everything. It's still possible, though, to rebuild "png",
reinstall an "imlib" package that's built against the old "png", and
then build "gnome" and a whole bunch of other things, none of which
will work!

> 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.

Yes, that is unfortunate. The whole problem with png, though, is that
the oldest png packages really don't work, because we've had to patch
some packages to utilize the new interface, and other packages have no
doubt been updated to that effect by the original authors.

If you have a very recent png, you could probably get away with
commenting out the DEPENDS in a package before building it. If your
"knews" or "ImageMagick" works and displays png's, no harm done.
(Either that, or time-travel to before the DEPENDS was bumped.)
The problem with explicitly accomodating pkgsrc users who don't want
to upgrade, is that some of these "users" are also developers who make
binary packages for mass consumption. Moreover, it's not their fault.
A _package_ system that's not designed, foremost, to build binary
packages is pretty weak.

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

I think we're all pretty much in agreement that's there's no other
way, as far as the first DEPENDS bump goes (which is already done).
I'm arguing that we should also close the holes for the intermediate
packages, like "imlib" and "gnome-libs". It seems like a lot of work,
but it's all mechanical. I wouldn't mind doing it myself, but I'd like
everyone to understand, first, why it needs to be done.


Frederick