search

Cisco-Talos / clamav

ClamAV - Documentation is here: https://docs.clamav.net
https://www.clamav.net/
GNU General Public License v2.0
4.43k stars 706 forks source link

1.4-rc needless bumps major so #1296

Closed sebastianas closed 3 months ago

sebastianas commented 4 months ago

I've been looking at commit e6b2e5d1a78e3f592280791a740c786e0d037af7 and from what I can tell this does not qualify for a major so bump. It is said a macros like CL_SCAN_PARSE_IMAGE has been added. This does not matter. "Older" code can use the library without any trouble. It will just not use this. The code does not require the macro to be set. It is optional as far as I can tell. Having this bump requires to recompile all users of the library and I don't see how the result is different except it links now against libclamav13 instead of libclamav12.

Looking at libclamav.map since 1.3.0 release, I see functions removed but only in the CLAMAV_PRIVATE section.

Is there something I have overseen?

Since I have libclamav.map open, why do we still have CLAMAV_1.0.0…CLAMAV_0.104.0 around? There was a so bump after this was introduced (so 11 -> 12) so this could have been cleaned up. I asked not to introduce them in the first place because they did not solve a problem nor served they another purprose.

A valid use case this would be to add cl_retflevel into each released version. The problem is:

The way this is done now is that there is no difference between libclamav 1.3.0 and 1.3.1 so packageX could be updated before libclamav is updated. However packageX will complain on startup. Therefore I have to manually update the dependency for cl_retflevel on each version update. Solving this with the version string would require to add cl_retflevel on each version in one of the version strings. Now, I', not asking pointing out a valid use case ;) Also, adding a new exported in a new version would require one of these to record the version dependency properly. Therefore after a major so bump (11->12), all of this gone and you can start from scratch having only a CLAMAV_PUBLIC.

Sebastian

micahsnyder commented 4 months ago

@sebastianas Thank you for investigating. You're quite right about the macro additions not requiring a version bump. I've added a commit to fix the SOVERSION prior to 1.4.0 stable release. Does this look right to you? https://github.com/Cisco-Talos/clamav/pull/1280/commits/23ba6d8b3c982a0748271d40fcffdec31212091d

Since I have libclamav.map open, why do we still have CLAMAV_1.0.0…CLAMAV_0.104.0 around? There was a so bump after this was introduced (so 11 -> 12) so this could have been cleaned up. I asked not to introduce them in the first place because they did not solve a problem nor served they another purprose.

I think I understand. So let's plan to remove CLAMAV_1.0.0…CLAMAV_0.104.0 next time when we actually bump from 12 -> 13?

sebastianas commented 4 months ago

On 2024-07-08 09:47:35 [-0700], Micah Snyder wrote:

@sebastianas Thank you for investigating. You're quite right about the macro additions not requiring a version bump. I've added a commit to fix the SOVERSION prior to 1.4.0 stable release. Does this look right to you? https://github.com/Cisco-Talos/clamav/pull/1280/commits/23ba6d8b3c982a0748271d40fcffdec31212091d

Yes, thank you.

Since I have libclamav.map open, why do we still have CLAMAV_1.0.0…CLAMAV_0.104.0 around? There was a so bump after this was introduced (so 11 -> 12) so this could have been cleaned up. I asked not to introduce them in the first place because they did not solve a problem nor served they another purprose.

I think I understand. So let's plan to remove CLAMAV_1.0.0…CLAMAV_0.104.0 next time when we actually bump from 12 -> 13?

Yes, thank makes sense. Thank you.

Sebastian