![](https://secure.gravatar.com/avatar/10a3ceea7f0886152bd6ee6fb28b3579.jpg?s=120&d=mm&r=g)
(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.) Python is nice enough to keep its modules in a <major>.<minor> versioned directory, so footprint mismatches are rare, and when they do occur, it's a pretty good hint that the modules *needs* to be re-tested. However, 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. 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. Perl (and Python, which doesn't even promise bytecode compatability between micro version upgrades) modules is no exception to this. 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. 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.) And as can be witnessed by the attached suggested patch, implemention is trivial. With that said, nobody died from bogus footprint mismatches fo far, so if the proposal is rejected, that's fine - I just want to be sure it happens for the right reasons :)