dev-libs/cln-1.1.5 creates libcln.so.2.0.4. When upgrading to dev-libs/cln-1.1.6, it creates libcln.so.3.0.0, without preserving libcln.so.2.0.4. It seems to me that either dev-libs/cln-1.1.6 should have a new slot, or it should preserve libcln.so.2 (if present). See bug #32510 for a similar situation with libgdbm. In the patch to bug #32510, the following code was used to protect libgdbm.so.2, since gdbm-1.8.3 created libgdbm.so.3: # temp backwards support #32510 if [ -e ${ROOT}/usr/lib/libgdbm.so.2 ] ; then cp ${ROOT}/usr/lib/libgdbm.so.2 ${D}/usr/lib/ touch ${D}/usr/lib/libgdbm.so.2 If this approach is the correct one, then the following patch should be applied to cln-1.1.6.ebuild: if [ -e ${ROOT}/usr/lib/libcln.so.2 ] ; then cp ${ROOT}/usr/lib/libcln.so.2 ${D}/usr/lib/ touch ${D}/usr/lib/libcln.so.2 Reproducible: Always Steps to Reproduce: 1. emerge =dev-libs/cln-1.1.5 2. emerge =dev-libs/cln-1.1.6 Actual Results: dev-libs/cln-1.1.6 deleted libcln.so.2 while creating libcln.so.3 Expected Results: dev-libs/cln-1.1.6 should have kept libcln.so.2 AND created libcln.so.3
There aren't many packages around using cln, and none of them are vital for system operation. Now we have to choose between using revdep-rebuild and re-emerging three packages or opening a can of worms (IMHO) by always preserving old libraries without having a way to clean them up if they are no longer needed. I tend to prefer revdep-rebuild in this case. Please re-open this bug if you strongly disagree.
