[Pkg-clamav-devel] Processing of clamav_0.98.4+dfsg-1_i386.changes

[Andreas Cadhalpun]

Hi,

On 03.07.2014 22:03, Sebastian Andrzej Siewior wrote:
> On 2014-07-03 21:26:49 [+0200], Andreas Cadhalpun wrote:
>>>> I see you backported a patch to expose cl_initialize_crypto in clamav.h.
>>>> Have you already tested/patched the reverse dependencies?
>>
>> Looking closer, I think now that cl_initialize_crypto and cl_cleanup_crypto
>> are in clamav.h, they should be moved from CLAMAV_PRIVATE to CLAMAV_PUBLIC
>> in libclamav/libclamav.map.
>
> This has any meaning?

Yes. All symbols available via public headers are marked as 
CLAMAV_PUBLIC, and the other ones as CLAMAV_PRIVATE.
Upstream hasn't changed the status for cl_initialize_crypto and 
cl_cleanup_crypto yet, but if they regard them as public API, I expect 
they will change this before the next release.
Then we would have to make another transition, or the binaries compiled 
with the CLAMAV_PRIVATE versions would not find the symbols anymore.

> Regarding the bugs here. I might have talked upstream into moving
> cl_initialize_crypto() into the other init function. Lets see how that
> goes. If it works, we are done :)

That would spare us some troubles.

>>> - havp: #753530
>>>    doesn't look very well maintained. For that reason we might want to
>>>    bump the so number of the version to make sure the "old" version works
>>>    even if nobody updates the packages.
>>>    Besides that, it is only on unstable so we don't have to worry about
>>>    stable :)
>>
>> Not very well maintained means in this case completely unmaintained since
>> three years. Given that it has now 5 RC bugs, it's probably best to remove
>> it from the archive.
>
> Well, if it wouldn't be for havp we wouldn't know it by now I think :)

Yes, but I think it wasn't a Debian user who reported that, or was it?

> But you made a fair point.
>
>>> - dansguardian: #753533
>>>    I opened that bug against stable. Which remainds, shouldn't oldstable
>>>    be gone by now?
>>
>> It has the same version in stable and unstable, so the stable update is just
>> the same as the update in unstable.
>>
>>> - c-icap-modules: started yesterday, should be finished by tonight :)
>>
>> OK.
>
> Patch ready but posponed due to what I just wrote about moving
> cl_initialize_crypto().

I see.

Best regards,
Andreas