Bug 224492 - mail/mimedefang fails seeking clamav when configured not to
Summary: mail/mimedefang fails seeking clamav when configured not to
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Tobias Kortkamp
URL:
Keywords: easy
Depends on:
Blocks:
 
Reported: 2017-12-20 22:50 UTC by mstowe
Modified: 2019-09-02 08:05 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback+
koobs: merge-quarterly-


Attachments
patch (1.02 KB, patch)
2018-02-26 22:06 UTC, m.tsatsenko
m.tsatsenko: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mstowe 2017-12-20 22:50:07 UTC
This is a regression versus 2.78, where I note that various "--disable-clamav" flags were passed along to the makefile if ClamAV was NOT selected in the config.  In this version, NOT selecting ClamAV results in behavior where mimedefang will build to REQUIRE clamav but not use it as a DEPENDENCY which is ... pretty obnoxious at best.  Recommend gleaning the working parts of the Makefile from 2.78.
Comment 1 m.tsatsenko 2017-12-21 21:18:58 UTC
Hello.
Thanks for informing me, but I did not get it. Could you please provide some additional details i.e. logs,  make config output etc. And what exactly you want me to remove from Makefile
Comment 2 mstowe 2017-12-22 17:05:20 UTC
It's something to add [back] to the Makefile, the missing options.  Specifically, this clause was in the 2.78 Makefile:

.if defined (MIMEDEFANG_DISABLE_CLAMAV) || ! ${PORT_OPTIONS:MCLAMAV}
CONFIGURE_ARGS+=        --disable-antivirus \
                        --disable-clamav \
                        --disable-clamd
.else
BUILD_DEPENDS+= clamscan:${PORTSDIR}/security/clamav
RUN_DEPENDS+=   clamscan:${PORTSDIR}/security/clamav
.endif

In the new Makefile, this has been replaced with the inexplicably hard-coded:

CLAMAV_BUILD_DEPENDS+=          clamscan:security/clamav
CLAMAV_RUN_DEPENDS+=            clamscan:security/clamav
CLAMAV_CONFIGURE_ENABLE+=       antivirus clamav clamd

Though the config hasn't had the "ClamAV" option removed, so I assume it's an oversight, and not a campaign to force people to install and use ClamAV.
Comment 3 m.tsatsenko 2018-02-25 21:25:52 UTC
Hello,
I have just tried to build the port without ClamAV and it is perfectly fine. At least in poudriere
Could you please provide some logs with an actual error message?
Comment 4 mstowe 2018-02-26 00:25:54 UTC
Yes, it builds fine, but it creates a RUNTIME dependency on ClamAV...  which, of course, means that Mimedefang doesn't work unless ClamAV is installed.

Steps to reproduce:
1) Ensure ClamAV is NOT installed on your system
2) UNcheck the "Enable Clamav" in mimedefang make config
3) mimedefang make install
4) try to run mimedefang, it will work
5) have mimedefang process something <- here's where it will fail

Since I have included the COMPLETE FIX for the issue, and the steps above will reproduce it, I imagine this should be sufficient, but let me know if you still have trouble figuring this out.
Comment 5 m.tsatsenko 2018-02-26 01:31:37 UTC
Thanks for the clarification. I have figured out that entire CLAMAV_* section is noop.
Will submit a fix for this tomorrow.
Comment 6 m.tsatsenko 2018-02-26 22:06:31 UTC
Created attachment 191030 [details]
patch

Please try the patch attached.
Comment 7 Walter Schwarzenfeld 2018-09-02 17:26:58 UTC
Reporter feedback please!
Comment 8 Kubilay Kocak freebsd_committer freebsd_triage 2019-08-07 01:47:10 UTC
Patch (maintainer approved) looks good to fix the reported issue.

Explicit confirmation of QA (poudriere) passing with expected behaviour in both CLAMAV option enabled/disabled cases would be great.

Port bugfix, MFH
Comment 9 m.tsatsenko 2019-09-01 20:05:32 UTC
Well it appears this one was fixed already see ports r495764
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2019-09-02 04:42:25 UTC
Assign to committer that resolved

Re-open for MFH (quarterly is affected)
Comment 11 Tobias Kortkamp freebsd_committer freebsd_triage 2019-09-02 05:03:59 UTC
(In reply to Kubilay Kocak from comment #10)
2019Q3 is not affected. ports r495764 was committed in March.