Subject: And speaking of PKGREVISION: Perl version bumping
To: None <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 01/05/2005 16:45:00
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).
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.
Then again, while non-.so modules do still work thanks to builtin
compatibility logic in perl, their pathnames in the binpackage change.
That would technically also warrant a PKGREVISION bump. That's ugly,
considering the number of p5-* packages, but under established policy, it's
the way things are supposed to happen.
Opinions, thoughts on how to alleviate this problem? Should we just go with
a forced PKGREVISION bump sweep when the Perl version number changes (thus
changing its pathnames)?
-- Todd Vierling <firstname.lastname@example.org> <email@example.com>