On Fri, Feb 16, 2018 at 07:05:41AM -0500, The Wanderer wrote: > Package: libcomerr2 > Version: 1.43.8-2 > Severity: normal > > Dear Maintainer, > > libcom-err2, which is currently at version 1.43.9-1, currently Breaks: > any libcomerr2 package of a lower version. This is normal and > reasonable. > > There is a libcomerr2 package of matching version, which is labeled as a > transitional package. This is normal, and working fine. > > However, there does not appear to be any libcomerr2:i386 > transitional-package version. The most recent version of libcomerr2:i386 > available in current testing is 1:43.8-2. (The packages.debian.org pages > for libcomerr2 that I know to check show nothing to indicate that this > version is expected to be absent, and I have been unable to find any > indication of its having been rejected for testing migration for > whatever reason, but it is nevertheless not available.)
There is a libcomerr2:all package which is in in testing: https://packages.debian.org/buster/libcomerr2 > As a result, when I attempt to dist-upgrade, apt-get proposes to remove > libcomerr2:i386, and everything that (directly or indirectly) depends on > it; that includes at least one package which I actively want to retain. > (pcsx2, for what it's worth.) What I believe *should* have happened is that apt-get should have replaced libcomerr2:i386 with the new version of libcomerr2 of type any. If I had created separate transition packages for each architecture separately (e.g., libcommerr2:i386, libcomerr2:amd_64, etc. I belive I would have gotten Lintian errors and complaints that I was wasting ftp space on all of our mirrors). Cheers, - Ted