Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
On Thu, Feb 22, 2018 at 04:06:06PM -0500, Theodore Ts'o wrote: > > Thanks for the patch and the explatnation. Hmmm... so that memans > that if a package is every Arch:all, it's impossible to ever > transition to Arch:any without running afoul of the potential for the > package to be installed for multiple architectures. Grump. The inverse, surely. If it's :any (and m-a:same), changing it to :all won't work *if it has deps*. If there weren't deps involved here, it would be fine, since replacing two installations of old-package with one installation of new-package would be exactly what you wanted. But, due to there being deps, you end up with a situation where: 1) We upgrade any->all on the primary arch (say, amd64). 2) libold:amd64 brings in libnew:amd64, but nothing pulls in libnew:i386. 3) libold:i386 and libold:amd64 are now different versions. 4) The situation in (3) isn't allowed, so we remove i386. 5) Anything that depended on libold:i386 now needs to be removed. Anyhow, with the exception of transitionals, it seems generally weird that one would want to go from any+same to all, as those tend to cater to very different types of packages, so meh. ... Adam
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
On Thu, Feb 22, 2018 at 09:32:53AM -0700, Adam Conrad wrote: > > In Ubuntu, the attached patch was applied to achieve the following: > > * Make transitional library packages be Arch: any and Multi-Arch: same > so that upgrades actually function correctly when two or more exist. > > It's clear from the multiarch spec that only one arch:all package > can be installed (ie: you can't have an amd64 and i386 version of > the same arch:all package, that's nonsensical), and thus this upgrade > path just doesn't work for people who had multiple versions of the > libraries installed. Flipping the transitionals back to arch:any > and m-a:same fixes the upgrade. Thanks for the patch and the explatnation. Hmmm... so that memans that if a package is every Arch:all, it's impossible to ever transition to Arch:any without running afoul of the potential for the package to be installed for multiple architectures. Grump. It doesn't matter here, since this is only at transitional package, but this seems unfortunate. - Ted
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
Package: e2fsprogs
Version: 1.43.9-1
Followup-For: Bug #890590
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch
In Ubuntu, the attached patch was applied to achieve the following:
* Make transitional library packages be Arch: any and Multi-Arch: same
so that upgrades actually function correctly when two or more exist.
It's clear from the multiarch spec that only one arch:all package
can be installed (ie: you can't have an amd64 and i386 version of
the same arch:all package, that's nonsensical), and thus this upgrade
path just doesn't work for people who had multiple versions of the
libraries installed. Flipping the transitionals back to arch:any
and m-a:same fixes the upgrade.
... Adam
-- System Information:
Debian Release: buster/sid
APT prefers bionic
APT policy: (500, 'bionic')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.13.0-32-lowlatency (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru e2fsprogs-1.43.9/debian/control e2fsprogs-1.43.9/debian/control
--- e2fsprogs-1.43.9/debian/control 2018-02-08 11:09:49.0 -0700
+++ e2fsprogs-1.43.9/debian/control 2018-02-19 06:05:49.0 -0700
@@ -49,7 +49,8 @@
Package: libcomerr2
Depends: libcom-err2, ${misc:Depends}
-Architecture: all
+Architecture: any
+Multi-Arch: same
Priority: optional
Section: oldlibs
Description: transitional package
@@ -131,7 +132,8 @@
Package: e2fslibs
Depends: libext2fs2, ${misc:Depends}
-Architecture: all
+Architecture: any
+Multi-Arch: same
Priority: optional
Section: oldlibs
Description: transitional package
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
On 2018-02-16 at 12:31, The Wanderer wrote: > On 2018-02-16 at 11:42, Theodore Ts'o wrote: >> 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... Having thought about it again (in the shower), I suspect that the solution is simply to make the transitional package M-A:same, just as the library package itself is (at least going by my, admittedly extremely limited, understanding of the multiarch spec). It looks to me as if any package which needs its dependencies to be the same architecture as itself - as a library-transition package does - effectively needs to be M-A:same, even if no files within that package vary between architectures. -- 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
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
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
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
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
Bug#890590: libcomerr2:i386: no available i386 variant of transitional package
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.) 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.) Please make sure that the i386 transitional package, suitable to satisfy this dependency chain, is available alongside the amd64 one. It may also be worth checking into whether transitional-package versions for any other architectures are also MIA. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.0-3-amd64 (SMP w/12 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages libcomerr2:i386 depends on: ii libc6 2.26-6 libcomerr2:i386 recommends no packages. libcomerr2:i386 suggests no packages. -- debconf-show failed
