On Thu, 22 Aug 2002, Dr. Rene Hexel wrote:

> On Thursday, August 22, 2002, at 09:33  AM, Frederick Bruckman wrote:
>
> > 	# pkg_info -R 'libogg*'
> > 	Information for libogg-1.0.0.8:
> >
> > 	Required by:
> > 	libvorbis-1.0.0.8
> > 	xmms-1.2.7nb1
> >
> >
> > 	Information for libogg-SO-1.0.0.7:
> >
> > 	Required by:
> > 	vorbis-tools-1.0.0.7nb1
> > 	gqmpeg-0.16.0nb1
>
>    That looks nice, I like that a lot.  You might want to make
> libogg-SO-1.0.0.7 depend on libogg-1.0.0.8, though.  Otherwise
> libogg-1.0.0.8 could be deinstalled, leaving around a bunch
> of packages that depend on the (now useless) old version of
> the library.

libogg-SO-1.0.0.7 doesn't depend on anything in libogg-1.0.0.8.
If you delete libogg-1.0.0.8, you'll leave a libogg-SO-1.0.0.8,
containing libogg.so.4.0 and libogg.so.4, to satisfy any dependencies.
There was a major bump between 1.0.0.7 and 1.0.0.8, so packages really
will depend on one or the other, so that makes perfect sense.

The non-intuitive part, is when you update minor only. I now have a
png-SO-1.2.1, containing only libpng.so.3.0, which has many
dependents, even though the dependent's binaries are really running
against libpng.so.3.1, since that's where libpng.so.3 points (assuming
they depend on libpng at all -- that's another story). That doesn't
seem to cause any trouble: the last libpng.so.3.* to be installed
always has the major symlink pointing to it, and anything that needs
that, will depend on one png or another. In other words, the SO thing
is a trick, to satisfy the package tools -- there's really "only one"
png package installed at any given time (with extras), and you can
list all of its dependents with "pkg_info -q -R png\*".

>    This also would have the advantage that a 'make update' for
> libogg should work as expected and cleanly update everything
> that depends on both the old and the new version of the library.

"make update" becomes "make install", for most purposes. The hack
adds any SO packages in the dependencies to the list of packages to be
built, so you can't go wrong there.

If you really want to upgrade *all* the dependents cleanly, you only
need a tool to put them in order. E.g:


	su
	CDPATH=".:/usr/pkgsrc:$CDPATH"
	cd /var/tmp
	for p in `pkgorder -r -I png-SO`
	do
		pushd $p
	done
	while [ "$PWD" != /var/tmp ]
	do
		(make package && make clean) && popd || break
	done


and now, if a build chokes, you're left in the directory of the
package that failed, all dependents remaining fully functional.
There's a draft manpage for "pkgorder" in the "pkg_hack" tarball.
(It should probably have examples like the one above.)


Frederick