New major upstream version for clamav

[mommsen]

Upgrade clamav to version 0.101.0, which introduces new library versions. Keep the previous version 0.100.1 around to satisfy the shlibs policy. This pull request replaces #316, which got messed up.

[nieder]

Sorry for the delay, this dropped off my radar. I looked back at the history of the clamav commits and saw that we were dropping the older clamavN-shlibs packages as they were replaced/updated, since clamav is the only package that uses them. I hadn't realized that aspect when I first brought up Shlibs policy.
Is there a chance that another package might decide to use the libclamav.N.dylib files? If not, that suggests that they can be converted into private dylibs, merged into the base clamav package, and clamav8-shlibs be obsoleted.
Your current 2 files are OK I think. I can suggest some changes to make updating in the future easier if we're keeping the older version around.

[mommsen]

I considered following the suggestion of making the shlibs private, as suggested by @remkos in #316. However, I would like not exclude the possibility to link against the clamav shlibs in future. Therefore, I decided to keep the old version around. Any suggestions on how to make this easier, are very welcome. Thanks!

Remi

[nieder]

Fair enough. Look at any of the files in main/libs like libpano13.3-shlibs that have made the library the primary package instead of the executables. This layout is particularly useful when you have multiple libN versions of the general package present. And if you decide to keep clamav8-shlibs around, but see no need to keep the user binary and daemon around, all you do is remove those SplitOffs and rm the files during installScript and all that's left is the library and you didn't have to shuffle .info file names.

[nieder]

Fair enough. Look at any of the files in main/libs like libpano13.3-shlibs that have made the library the primary package instead of the executables. This layout is particularly useful when you have multiple libN versions library available. And if you decide to keep clamav8-shlibs around, but see no need to keep the user binary and daemon around, all you do is remove those SplitOffs and rm the files during installScript and all that's left is the library and you didn't have to shuffle .info file names.

So you would have something like clamav9-shlibs.info, {Compile,Install}Script would stay the same, ConfFiles would move into a new SplitOff: clamav. clamav9-dev and clamav-daemon would stay the same, and the Shlibs: field would move out of the current clamav9-shlibs SplitOff into the base package (since that's what now carries the dylib). You might need to tweak the Files fields to make sure clamav9-shlibs is left only with the versioned dylib.

[mommsen]

I have finally implemented the refactoring into shlib packages following @nieder suggestions. Please let me know if you see any issues with the new packages. Thanks!

[nieder]

Sorry, I lost track of this. Transition to clamav#-shlibs.info seems mostly OK.

1. The current zlib check using the SDK on 10.12 is fatal. If you conditional the SDK_PATH check to Xcode 10 (or maybe macOS 10.14) and up, and change the configure parameter to be --with-zlib=$SDK_PATH/usr, then the zlib check proceeds and everything builds on 10.12.

I don't have the exact syntax, but something like:

if [ xcode_version >= 10 ]; then
  SDK_PATH=`xcrun --sdk macosx --show-sdk-path`
else
  SDK_PATH=''
fi
./configure ... --with-zlib=$SDK_PATH/usr

2. The PostInstScript and PreRmScript fields (lines 229-253) are currently part of the clamav9-shlibs parent package. They need to be moved back into the SplitOff3 field for the user facing clamav package in clamav9-shlibs.info to match where they need to be like in the old clamav.info file.

3. InfoTest needs TestDepends: check.