github CI: remove tags from container names

[neheb]

No description provided.

[ghost]

👇 Click on the image for a new way to code review

Legend

[codecov]

Codecov Report

Merging #2728 (9f97144) into main (901e8ba) will increase coverage by 0.01%.
Report is 48 commits behind head on main.
The diff coverage is 83.33%.

❗ Current head 9f97144 differs from pull request most recent head 9908f75. Consider uploading reports for the commit 9908f75 to get more accurate results

@@            Coverage Diff             @@
##             main    #2728      +/-   ##
==========================================
+ Coverage   63.89%   63.91%   +0.01%     
==========================================
  Files         103      103              
  Lines       22313    22313              
  Branches    10799    10806       +7     
==========================================
+ Hits        14258    14261       +3     
+ Misses       5830     5828       -2     
+ Partials     2225     2224       -1     

Files Changed	Coverage Δ
include/exiv2/value.hpp	84.90% <ø> (-0.22%)	⬇️
src/canonmn_int.cpp	73.17% <ø> (+0.29%)	⬆️
src/casiomn_int.cpp	6.45% <ø> (ø)
src/fujimn_int.cpp	39.62% <ø> (ø)
src/makernote_int.cpp	65.91% <ø> (ø)
src/nikonmn_int.cpp	61.20% <ø> (ø)
src/olympusmn_int.cpp	45.39% <ø> (ø)
src/panasonicmn_int.cpp	52.58% <ø> (ø)
src/pgfimage.cpp	42.76% <0.00%> (ø)
src/preview.cpp	45.02% <ø> (ø)
... and 22 more

[neheb]

@Ryanf55 see last commit as an example of how to try to fix this garbage with this bug in place. Way too much code needs to be written(missing overridden destructors, same needs to be done with static const, etc...).

[Ryanf55]

@Ryanf55 see last commit as an example of how to try to fix this garbage with this bug in place. Way too much code needs to be written(missing overridden destructors, same needs to be done with static const, etc...).

Not clear - are you asking me to fix it everywhere? I don't have time other than the bare minimum. We're using Linux with 3.27 CMake and it compiles fine with all the patches I put in, so that's about all I can support here.

Just a note = If the link error was caused by upgrading CMake, you could set the corresponding CMake policy to preserve <=3.26 behavior, if there's a policy for it. That would affect the whole build, and buy you some time.

[neheb]

No I was pointing out that fixing it this way is impractical. The other PR has a normal fix.