tis 2022-06-14 klockan 01:36 +0000 skrev Felicia P: > Package: libgsasl7 > Version: 1.10.0-5+b1 > Severity: important > > Dear Maintainer, > > libgsasl7 depends on gsasl-common 1.10.0-5 however the current > version of gsasl-common is now 1.11.3-2 Thanks -- this is related to the transition to libgsasl18, so cc'ing 1012768 too. Any help to resolve this would be appreciated! I must admit that my brain cannot really understand all the complexities around library transitions. The situation appears to be: 1) Testing contains libgsasl7 1.10.0-5 that has a hard versioned dependency on gsasl-common 1.10.0-5 for translation files. 2) Unstable now has libgsasl18 1.11.3-2 that depends on gsasl-common 1.11.3-2. 3) Libgsasl7 is no longer built by the gsasl source package, and the idea is that it should go away. 4) The old libgsasl7 is not installable since it depends on a gsasl- common package that is no longer in unstable. What should be done here? I guess the idea is that all packages that are built against libgsasl7 is going to be NMU'd through the transition, so that they are built against libgsasl18 instead. Then this shouldn't be a problem. However, maybe something more should be done anyway. Some ideas: A) We declare that gsasl-common >= 1.11.3-2 conflicts with libgsasl7. Doesn't really solve anything, but maybe it will lead to libgsasl7 being uninstalled automatically? B) Somehow drop the gsasl-common dependency? It only contains translations, which works for both libgsasl7 and libgsasl18. C) Change the versioning dependency, so that new gsasl-common satisfy the old libgsasl7 dependency -- but I'm not sure that's possible, libgsasl7 depends on the same version of gsasl-common. I guess this means that libgsasl7 and libgsasl18 cannot be installed on the same system ever, due to the gsasl-common versioned dependencies. That is unfortunate, since there is no real problem with having both versions installed. Maybe B) is the right solution?! We could move the translations into libgsasl18 and drop gsasl-common. Then old libgsasl7 could depend on gsasl-common and things will work, and you could have libgsasl18 installed too -- however, they would conflict in files since both ship the same translation files... unless we modify the filenames so they live in separate directories or basenames. I'm not sure that is worth it. It may also be that we can't fix this problem, and just live with the consequences. What is the real problem here? All dependencies on libgsasl7 should be rebuilt and then link to libgsasl18. Libgsasl7 will disappear from testing shortly. I wonder if it was a mistake to put translations in gsasl-common?! I recall a lot of thought went into that but it was many years ago and maybe the best practice around this has changed. /Simon
Attachment:
signature.asc
Description: This is a digitally signed message part