On Thu, 24 May 2001, Frederick Bruckman wrote:

> > 	Hmm - the 'make update' in png also rebuilt imglib, so I _should_
> > 	have been OK on that front?
>
> Not really. Someone's going to try to install "gnome" from binaries on
> the ftp site, and it's going to be all messed up, because some
> packaged binaries will need libpng.so.1.0, and some binaries will need
> libpng.so.2.0, and there'll be no way to distinguish which combination
> of packages will work. Worse, since packages are going to be
> overwritten with identically versioned ones, there may be no way to
> install gnome at all, unless the entire collection is rebuilt from
> scratch.
>
	I understand that case, but in my situation I ran a 'make update'
	in graphics/png, so it should have rebuilt gnome-core, which is
	what is confusing me.

> As much trouble as it is to walk up the chain from png, bumping
> dependencies and "nb" versions, at least there _is_ a right to handle
> it. For shared libraries which could optionally exist in the base
> system (I'm thinking openssl), there's no right way to do it, unless
> you were to insist on using the pkgsrc version for NetBSD-1.5.x, which
> would really suck.
>
	This happens way to often (at the Wakefield show we found we
	had a broken dia package as the packages were built on different
	machines and one of the gnome libs had had a major bump between
	the builds).

	I completely agree we should have a policy of bumping all
	depending packages when a shared library version is changed.

> > 	As an added bonus rebuilding gnome-libs has made the gnome_segv
> > 	program work so I can see that gnumeric is getting a segv, but
> > 	leaves me no closer to a working gnumeric.
> >
> > 	I'm probably going to have to delete and rebuild all packages on a
> > 	non production box to see if its upgrade related or a problem with
> > 	a change in a package.
>
> Did you see any warnings at link time? Like, "built-in dependency of
> libfoo on libpng.so.1 conflicts with built-in dependency of libbar on
> libpng.so.2"? Does "ldd /usr/X11R6/bin/gnumeric" show any sign of
> libpng.so.1.?

	ldd of gnumeric shows only libpng.so.2, and its now been rebuilt
	again with the new gnome-core.

	I think there were two issues.

	   - gnome-core was not rebuilt correctly after png. This _could_
	     have been an old version of gnome-core left in the work
	     directory. I'm usually quite reliable at wiping /var/obj/pkg
	     before rebuilding, but that is the only option I can see that
	     makes sense (the datestamps in /var/db/pkg/gnome-core*/* were
	     after /var/db/pkg/png*/*). Hubert's latest 'check versions
	     on install' changes (Thanks Hubert!) should make sure that
	     does not happen again... providing we bump versions.

	   - gnumeric is getting a segv.
	     Buggered if I know. I'm running a -current kernel with
	     1.5.1_BETA2 userland on my laptop, and most everything is
	     -march=pentiumpro, so there could be an issue there (though
	     it worked find before the png update. I'm building gnumeric
	     on a 1.5-release kernel & userland machine to see if it
	     has problems there (and if it does I'll delete every package,
	     reinstall 1.5 release and disable -march=pentiumpro to get
	     a real baseline).
-- 
		David/absolute		-- www.netbsd.org: No hype required --