Control: tags -1 moreinfo Control: severity -1 normal On 2021-03-09 Davide Prina <davide.pr...@gmail.com> wrote: [...] > Some users in Italian mailing list have reported that they have an error > when they try upgrade/install packages: [...] > dig the problem we found that they have the following files on their system: [...] > $ ls -l /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5 > -rw-r--r-- 1 root root 1112184 14 gen 2017 > /lib/x86_64-linux-gnu/libgcrypt.so.20.1.5
> but these files are from package migrated to testing in: > [2017-01-25] libgcrypt20 1.7.5-3 MIGRATED to testing (Debian testing > watch)[ยน] > So for some reason when the library path change they have not been deleted. Hello Davide, 1.7.5 is ancient, it was shipped in Debian during the development cycle of Debian 9 (stretch) but was not part of the Debian 9 (stretch) release. So the actual breakage happened when the user upgraded from 1.7.5-1/2/3 to some later version, using the Debian infrastructure (dpkg, apt, kernel, filesystem) at this point of time, probably in 2017. Another possibility would be that the user tried to upgrade from pre-oldstable directly to current-testing, skipping releases. If that is the case he/she is doing something we do not support. Do you have any further information on the upgrade, which version of libgcrypt was upgraded with what version of dpkg/apt to which version? [...] > I suggest to check that those file are removed from > /lib/x86_64-linux-gnu/ > in all new libgcrypt20 new version, elsewhere when Bullseye become stable > more user can have that problem. [...] Sure it is possible to apply a bandaid but this just scale. Packages normally need to be able to rely on dpkg to work. If it is a wide-spread problem the cost/benefit ration can make sense. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
