Bug 432176 - Please do not depend on perl devel packages
Summary: Please do not depend on perl devel packages
Alias: None
Product: Fedora
Classification: Fedora
Component: spamassassin
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Warren Togami
QA Contact: Fedora Extras Quality Assurance
Depends On:
Blocks: F9Target
TreeView+ depends on / blocked
Reported: 2008-02-09 12:04 UTC by Nicolas Mailhot
Modified: 2008-12-16 01:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-12-16 01:11:00 UTC

Attachments (Terms of Use)
Quick patch. (727 bytes, patch)
2008-02-12 02:03 UTC, Jason Tibbitts
no flags Details | Diff

Description Nicolas Mailhot 2008-02-09 12:04:50 UTC
Description of problem:

Somehow spamassassin sets a dependency on perl(ExtUtils::MakeMaker)

That means any desktop user with spamassassin as evo filter will pull the whole
perl devel stack

Please limit the dependencies on perl-devel to actual devel packages

# rpm -e perl-ExtUtils-MakeMaker
error: Failed dependencies:
	perl(ExtUtils::MakeMaker) is needed by (installed) spamassassin-3.2.4-1.fc9.x86_64

Comment 1 Kevin Fenzi 2008-02-10 03:22:51 UTC
This appears from first glance due to sa-compile. 

It writes out Makefile.PL files that have a "use ExtUtils::MakeMaker;" in it,
and rpm picks that up as a dependency. ;( 

I guess we need to filter our Requires out to get around that. ;( 

Comment 2 Warren Togami 2008-02-11 04:59:11 UTC
I agree that this should be filtered out.  But then how to do tell the user "you
are missing this perl component that is usually assumed to be there" when they
try to use sa-compile?

Comment 3 Ralf Corsepius 2008-02-11 07:06:48 UTC
I have no clue about spamassassin nor sa-compile, but the "standard answer
template" to cases like this is:

Split the component which pulls in otherwise not-required packages (usually
apps) into separate subpackages and let them pull in these deps (No idea if this
is possible with spamassassin).

If this isn't possible, you currently don't have much choice but to chose
between 2 evils: 
a) pull in the deps and live with the bloat they cause
b) don't pull in the deps and cope with users complaining about you shipping
defective/crippled packages.

In most cases, a) causes less troubles.

Comment 4 Warren Togami 2008-02-11 20:52:05 UTC
Bad news... I tried sa-compile without that dep, and the result is a totally
non-obvious error message.  I will ask upstream to see if it is possible to
display an obvious looking error message if ExtUtils::MakeMaker is not installed.

[root@newcaprica ~]# sa-compile
[15634] info: generic: base extraction starting. this can take a while...
[15634] info: generic: extracting from rules of type body_0
157.03 rules/sec 00m02s DONE
250.99 bases/sec 00m04s DONE
[15634] info: body_0: 684 base strings extracted in 8 seconds
[15634] info: rules: meta test FM_DDDD_TIMES_2 has dependency
'FH_HOST_EQ_D_D_D_D' with a zero score
[15634] info: rules: meta test FM_SEX_HOSTDDDD has dependency
'FH_HOST_EQ_D_D_D_D' with a zero score
[15634] info: rules: meta test HS_PHARMA_1 has dependency
cd /tmp/.spamassassin15634co47uItmp
cd Mail-SpamAssassin-CompiledRegexps-body_0
re2c -i -b -o scanner1.c scanner1.re
Can't exec "re2c": No such file or directory at /usr/bin/sa-compile line 281,
<$fh> line 987.
command failed! at /usr/bin/sa-compile line 282, <$fh> line 987.

Comment 5 Jason Tibbitts 2008-02-12 02:01:35 UTC
Actually, that error is from re2c not being installed (another soft dependency).
 The one where MakeMaker isn't there is significantly more confusing.  I'll
attach a patch that makes it a bit more obvious, but I doubt it's acceptable for
spamassassin upstream.

Comment 6 Jason Tibbitts 2008-02-12 02:03:19 UTC
Created attachment 294618 [details]
Quick patch.

With this you get:

Can't exec "re2c": No such file or directory at /usr/bin/sa-compile line 118.
/usr/bin/sa-compile requires re2c for proper operation.

if re2c isn't there, and

/usr/bin/sa-compile requires ExtUtils::MakeMaker for proper operation.

if MakeMaker isn't installed.

Comment 7 Warren Togami 2008-02-12 18:50:05 UTC
Upstream has accepted this patch.

OK, here are our options:
1) Split the package for this single file.  Undesirable for many reasons.  I
really want to avoid this.  We especially don't want to split it in a different
way than upstream splits their RPM because that is sure to add to confusion.
2) Leave it as is.  How mad will this make our users?
3) Filter the req.

This requires something like:
Source91:  filter-requires.sh
%define    _use_internal_dependency_generator 0
%define    __find_requires %{SOURCE91}

_use_internal_dependency_generator 0 has the drawback of disablin the part that
tags elf files as either 32 or 64-bit, so everything gets treated as a conflict.
   However spamassassin is not a multilib package so this is probably OK?

Perhaps we need perl SIG opinions here.

If this is OK, then I would prefer option #3, filtering the req.

Comment 8 Warren Togami 2008-02-12 18:51:15 UTC
Alternatively, is there any way the syntax within sa-compile could be rewritten
so find_requires does not see ExtUtils::MakeMaker?  This might be a simpler

Comment 9 Tom "spot" Callaway 2008-02-12 19:01:15 UTC
Even with the patch, I'm very hesistant to let you filter out this dep.

sa-compile actually does require ExtUtils::MakeMaker for proper operation. The
dep chain installed is necessary. If it is a serious annoyance, then sa-compile
should either be separated into its own package, or rewritten to use a module
that doesn't drag in as many dependencies.

Comment 10 Warren Togami 2008-02-13 00:43:52 UTC
I really don't want to split this package for a few key reasons:
- It is only a single script.
- Most users don't even use it.  It requires you to use it manually then
configure a non-default option to enable its use.
- We would have a different RPM split than upstream, further making it further
confusing to users.

I would prefer to leave the package as is if we are unable to filter the

Comment 11 Bug Zapper 2008-05-14 05:06:36 UTC
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:

Comment 12 Kevin Fenzi 2008-12-16 00:27:20 UTC
So, did we come to any conclusion here?
Leave it with the perl-devel requirement for now?

If so, can we close this now?

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