Bug 250007 - Please build perl(MIME::Tools) >= 0:5.413 for EPEL 4
Summary: Please build perl(MIME::Tools) >= 0:5.413 for EPEL 4
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: perl-MIME-tools
Version: el4
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Paul Howarth
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 250006
TreeView+ depends on / blocked
 
Reported: 2007-07-29 11:26 UTC by Robert Scheck
Modified: 2007-08-29 20:06 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-08-29 20:06:19 UTC
Type: ---


Attachments (Terms of Use)

Description Robert Scheck 2007-07-29 11:26:29 UTC
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.

Comment 1 Robert Scheck 2007-07-29 11:36:50 UTC
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 11:37:20 UTC
For reference: http://lists.roaringpenguin.com/pipermail/mimedefang/2004-
September/024530.html

Comment 3 Paul Howarth 2007-07-30 15:05:06 UTC
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.


Comment 4 Robert Scheck 2007-07-30 19:44:28 UTC
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 20:39:44 UTC
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 07:48:03 UTC
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 07:59:42 UTC
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 20:06:19 UTC
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.