Bug 250007 - Please build perl(MIME::Tools) >= 0:5.413 for EPEL 4
Please build perl(MIME::Tools) >= 0:5.413 for EPEL 4
Product: Fedora EPEL
Classification: Fedora
Component: perl-MIME-tools (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Paul Howarth
Fedora Extras Quality Assurance
Depends On:
Blocks: 250006
  Show dependency treegraph
Reported: 2007-07-29 07:26 EDT by Robert Scheck
Modified: 2007-08-29 16:06 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-29 16:06:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Scheck 2007-07-29 07:26:29 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):

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.
Comment 1 Robert Scheck 2007-07-29 07:36:50 EDT
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?
Comment 2 Robert Scheck 2007-07-29 07:37:20 EDT
For reference: http://lists.roaringpenguin.com/pipermail/mimedefang/2004-
Comment 3 Paul Howarth 2007-07-30 11:05:06 EDT
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

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.
Comment 4 Robert Scheck 2007-07-30 15:44:28 EDT
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 :)
Comment 5 Paul Howarth 2007-07-30 16:39:44 EDT
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.
Comment 6 Paul Howarth 2007-07-31 03:48:03 EDT
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).
Comment 7 Paul Howarth 2007-07-31 03:59:42 EDT
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...
Comment 8 Robert Scheck 2007-08-29 16:06:19 EDT
I'll close this bug report, as the main issue is resolved.

Note You need to log in before you can comment on or make changes to this bug.