Red Hat Bugzilla – Bug 250007
Please build perl(MIME::Tools) >= 0:5.413 for EPEL 4
Last modified: 2007-08-29 16:06:19 EDT
Description of problem: Please build perl(MIME::Tools) >= 0:5.410 for EPEL 4, because my MIMEDefang package has a run-time dependency on it. Version-Release number of selected component (if applicable): perl-MIME-tools-5.420-3 How reproducible / Actual results: Missing run-time dependency breaks MIMEDefang on EPEL 4 (detected recently by a new script). Expected results: Satisfied dependencies by having current perl-MIME-tools.
Ush..now I see, that version 5.113 or higher of MIME::Tools requires MIME::Base64 version 3.03 or higher. RHEL 4 includes only 3.01 within perl core. From reading the requirements of MIMEDefang depends on MIME::Base64 >= 3.03 and MIME::Tools >= 5.413. A suggested way by upstream would be to build a site-perl package providing a newer MIME::Base64, which is normally read after core, vendor but MIMEDefang is able to flip in site before core and vendor. Ideas? Suggestions?
For reference: http://lists.roaringpenguin.com/pipermail/mimedefang/2004- September/024530.html
Actually MIME::Tools will "work" with MIME::Base64 >= 2.20 but may fail to decode some binary attachments properly. Having version 3.03 available means that the 3-argument version of "encode_qp" can be used but it falls back to the single-argument version otherwise (see http://search.cpan.org/src/DSKOLL/MIME-tools-5.420/ChangeLog). So does MIMEDefang directly require 3.03 or later, or is this just an inherited dependency from MIME::Tools? EPEL packages are not allowed to replace/update base OS packages, so any workaround if needed would involve creating a private version of MIME::Base64 (and possibly MIME::Tools) where nothing else would find it and then hacking MIMEDefang to use the private version.
MIMEDefang depends on MIME::tools 5.413 or higher and MIME::Base64 3.03 or higher (as per MIMEDefang README file). I know, that EPEL packages are not allowed to replace/update core packages, so a working solution could be to use perl's site directory as this is normally read after the core and the vendor directory (the core directory always contains MIME::Base64 3.0.1 from perl package), which should be a clean solution. But maybe somebody with more perl knowledge should have a look to this idea. As I saw, you were importing perl-MIME-tools 5.420 or so to EPEL4 :)
If you're going to take the site directory approach, you'll need to bundle that with MIMEDefang rather than creating a separate package, reason being that a separate MIME::tools and/or MIME::Base64 package that installs there would be inconsistent with the rest of the EPEL perl modules and useless to anyone that didn't know they needed to fiddle the perl search path to use it. I expect that there's also a school of thought that the site directories should never be touched by RPM packages, much like /usr/local.
Here's my suggestion: Bundle a copy of MIME::Base64 >= 3.03 with MIMEDefang but install it somewhere private to that package, such as %{_datadir}/MIMEDefang/perl-modules-extra/ Then have MIMEDefang add this directory at the start of the perl module search path. This way, MIMEDefang gets the version it wants without disturbing anything else. MIME::tools will also see this updated version, but only when called from within MIMEDefang (MIME::tools 5.420 is already available in EPEL4 and EPEL5).
Actually you'd need to use something like %{_libdir}/MIMEDefang/perl-modules-extra/ rather than %{_datadir}/MIMEDefang/perl-modules-extra/ as MIME::Base64 is arch-specific...
I'll close this bug report, as the main issue is resolved.