On Wed, 5 Jan 2005, Todd Vierling wrote:

> So I ran into something today that was rather ... interesting.  We still
> have an issue with Perl, insofar that modules containing .so's cannot load
> any longer when the Perl package is updated.  I had modules compiled against
> 5.8.5, and when updating to 5.8.6, the existing binpkgs could no longer find
> libperl.so (because the rpath was now wrong).

I wonder if a symlink could be used for 5.8 and set the RPATH to use it
instead. I don't know if that is safe for all of these perl modules
though.

> PKGREVISION bumps are therefore warranted when p5-* modules contain .so
> shared object modules.  The big problem here is that the auto-packlist logic
> is hiding the presence of .so files in the modules, so we can't figure out
> (solely from pkgsrc data) which packages need a bump.

Maybe when PKG_DEVELOPER is set, have the PROVIDES saved on a deinstall
and then on an install compare it. This could give the developer a hint
for one package only though (and could be a reminder to bump the
PKGREVISION if needed).

Also a database of what packages provide could be used too. This is all I
have though for p5-* (based on packages for NetBSD/i386 2.0 on the FTP
server).

Name: p5-libapreq2-2.2.2
LibProvides: /usr/pkg/lib/libapreq2.so.2

Name: p5-subversion-1.0.8
LibProvides: /usr/pkg/lib/libsvn_swig_perl-1.so.0


 Jeremy C. Reed

 	  	 	 technical support & remote administration
	  	 	 http://www.pugetsoundtechnology.com/