On 2018-02-16 at 11:42, Theodore Ts'o wrote: > 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
Yes, I saw that page. >> 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 understand you correctly, I think that's what *is* happening - but the new libcomerr2 package apparently doesn't satisfy the i386 dependency. In fact, I think it's correct in not doing so, because it can't possibly know which non-native architectures of its dependency to pull in. The arch:all libcomerr2 depends on libcom-err2. Since that dependency does not explicitly specify any architecture, it resolves to the package version from the installed native architecture; in this case, that's libcom-err2:amd64. However, what is needed by the :i386 package declaring the dependency is libcom-err2:i386, which the arch:all libcomerr2 does not depend on. In the long run, the right solution is clearly for the depending packages (in this case, parts of krb5) to update their dependencies to libcom-err2. That doesn't affect the question of getting things to work cleanly during the transitional period, though. > 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). I'm not sure what the right way to handle this is, but having a single-architecture or non-architecture-specific transitional package attempt to substitute for all the cross-architecture dependencies clearly isn't working. I'd be glad to help with figuring out what to do on this, but if having a "separate" transitional package for each architecture isn't an option, I'm really not sure what might be... -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature
