Hi, On Fri, Apr 07, 2006 at 14:16:13 +0200, Mark Rosenstand wrote:
(This was filed in FS #37, but because of the comments, I'm lead to believe that it got rejected for the wrong reasons - so I'm opening it here for discussion, where we're not stuck in a stupid web interface.)
[...] because Perl puts its modules in a <major>.<minor>.<micro> directory, every upgrade triggers footprint mismatches for all Perl modules, most (all?) of which are bogus. Okay, I don't know perl well enough for me to confirm this. I'm sure however that 5.6 -> 5.8 wasn't compatible.
Since we're a source distro, our general upgrade logic is that when a library (or "module") is upgraded, it's a good idea to rebuild dependent packages. Yes, and for maintainers to test them against new versions
So, I suggest ignoring the perl version in the footprint like it already happens for kernel modules. Please note that it's the path in the footprint which is ignored, *not* the actual path in the file system. Also note that the purpose is to avoid bogus footprint mismatches in packages with Perl modules, not the perl package itself. However, those "bogus missmatches" don't happen if the port was tested (i.e. verified to work) with the current version of perl.
This means that when Perl is upgraded, it won't find the modules compiled for the old version (just like it happens now, so our upgrade logic is kept intact.) However, unlike it is now, noone can tell whether a packager verified a module against the current version of perl, and we can't run a simple grep to check the ports i.e. in a nightly consistency check.
I've mentioned this in the bug report, your patches provides a fix for exactly two cases: a) the packages are up to date, and the user uses an old version of perl b) the user has a current perl, and a packager didn't test his ports against the latest version of perl Both are not bugs in pkgmk, therefore I think the reason why I closed the bug is still valid: "[The] Patch is not fixing a problem of pkgmk but hides an actual issue of a port (not tested against the current version of perl), and potentially encourages maintainers to consider testing against new versions optional ("but the build works fine either way")" That said, I think your post focuses a bit much on your solution, and not the problem you're trying to solve. Assuming that micro-revisions seem to be compatible, I'd consider it the cleanest solution to look into the perl build files to make install to /usr/*/5.8/ instead of adding a work around to pkgmk. Best regards, Johannes -- Johannes Winkelmann mailto:jw@tks6.net Zurich, Switzerland http://jw.tks6.net