Bug 432176

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. ;( 

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?

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.

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
100%
[===================================================================================================================================================]
157.03 rules/sec 00m02s DONE
100%
[===================================================================================================================================================]
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
'HS_SUBJ_ONLINE_PHARMACEUTICAL' with a zero score
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.

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.

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.

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.

http://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies
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.

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
solution.

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.

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
requirement.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

So, did we come to any conclusion here?
Leave it with the perl-devel requirement for now?

If so, can we close this now?