Hi Roger, > On 6 Oct 2016, at 11:51, Roger Shimizu <[email protected]> wrote: > > I'm trying to handle the SONAME first, since the transition freeze > will come soon. > (although I'll try to not get involved in transition. explaining below) > > On Mon, Aug 29, 2016 at 10:23 PM, James Clarke <[email protected]> wrote: >> >> Whilst building the package, I couldn’t help but notice that libcork15 >> contains >> libcork.so.15, which is a symlink to libcork.so.16.0.1. This is clearly very >> very wrong (package name should be bumped up to libcork16, and the symlink >> should be called libcork.so.16). The cause of this is a crazy calculation in >> upstream’s cmake/FindCTargets.cmake, where on line 66 it does: >> >> math(EXPR __SOVERSION "${__VERSION_CURRENT} - ${__VERSION_AGE}”) > > I created the patch, just works as you suggested. > So could you kindly help to review it? > - https://github.com/rogers0/libcork/commit/8d45ec
Yes, that looks fine. Have you forwarded it upstream? >> This is then used to create the libcork.so.$__SOVERSION symlink, and given >> that >> __VERSION_CURRENT is 16 and __VERSION_AGE is 1, it calculates 16-1=15. >> __SOVERSION and __VERSION_CURRENT should be the same thing. Please request a >> transition, patch FindCTargets.cmake, bump the package name up to libcork16, >> upload the fixed version and file binNMUs. And, of course, get upstream >> patched. > > Since there's no ABI change from libcork15 to libcork16, they should > be no problem to replace the old with the new. > So here's my solution: > - https://github.com/rogers0/libcork/commit/f222c5 > > Do you think it's a good idea to avoid transition? If you’re doing that, I would consult other people (IRC is a good source), as I don’t know all the subtleties about package renaming and only have [1] to go on. However, IMO, given that you only have two reverse dependencies (namely src:shadowsocks-libev and src:libcorkipset), I would just do a transition and avoid picking up the cruft (and potential confusion), but I don’t have much experience of these things. Regards, James [1] https://wiki.debian.org/RenamingPackages
