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

Reply via email to