In message <1085834553.28696.197402550@webmail.messagingengine.com>, magetoo@fa
stmail.fm writes:
>
>Hi guys.
>
>
>  First of all, apologies if this is slightly off topic.  I don't know
>  exactly where it belongs.
>
>  I've been running 1.6 for some time now, and have always used binary
>  packages (off CD).  After getting my DSL connection, I'm thinking of
>  upgrading, and of using pkgsrc instead of binary packages.
>
>  Or more truthfully, I saw something cool and just had to have it, and
>  pkgsrc was conviniently there.
>
>
>  Now, source and binary packages don't seem to interact too well.  Is
>  that the way it is supposed to be?  The normal routine is that i cd to
>  some/package, make, and wait for the error message, which is usually
>  "somepackage requires somelib version 1.2.3, but it seems you already
>  have somelib 1.1.1 installed (old version?)"; and then pkg_delete -f
>  somelib and "make" again.  Not exactly optimal, I think.
>
>  Especially with packages with lots of dependencies.  I don't really
>  like having to rebuild something big like, say, Mesa, just to get xmms
>  working (which "packagely broke" after updating pth (which had to be
>  built so I could use Gaim)).
>
>  It will get easier in time, after all the big packages are built, but
>  is there a better solution?
>
>  This whole thing reminds me of my Debian experience, only back then I
>  didn't even have dialup.  Thanks to the fast connection it's a lot less
>  painful now.

The issue isn't source versus binary; it's a question of the age of the 
pkgsrc collection when the different pieces were built.  If the binary 
packages you installed were built from the same pkgsrc tree as you're 
using for compiling, it would all just work.  But you get into trouble 
if pkgrc is newer, even if you're dealing with packages you built from 
source.

The situation isn't pleasant.  It can lead to what I refer to as 
"pkgsrc hell"...

There are several approaches that one can take.  The simplest is to 
never update /usr/pkgsrc; that way, everything is consistent.  But 
that's a bad idea, if for no other reason than the occasional security 
hole in some package you've already installed.

The second approach is to use pkgdepgraph (yes, that's a package, too). 
Roughly speaking, if you've determined that a package is out of date -- 
let's assume that it's 'png' -- you run

	pkgdepgraph -R -O png >Rebuild

to get a shell script of what you'll need to do to reinstall everything 
that depended on png.  You then do

	pkg_delete `pkgdepgraph -D -O png`

to delete everything you're about to recompile, followed by

	sh Rebuild

Prepare to wait a while if it's something as pervasive as png...  
(Using pkg_delete -f is a very bad idea unless you *really* know what 
you're doing.)

The simplest way -- but the most time-consuming -- is to using

	pkg_chk -u

it will rebuild everything that's out of date.  That takes a while...

No, it's not great.  But there aren't great solutions here, unless 
there's a thorough archive of many different versions of many packages.
And it's even worse than I've just outlined, since you'll often find 
that something doesn't rebuild properly.

		--Steve Bellovin, http://www.research.att.com/~smb