Ticket #931 (closed defect: fixed)
Try and reduce dependence on ia32-libs
Reported by: | geofft | Owned by: | geofft |
---|---|---|---|
Priority: | blocker | Milestone: | Current Semester |
Component: | -- | Keywords: | |
Cc: | Fixed in version: | debathena-athena-libraries 1.5 | |
Upstream bug: |
Description
Evan tells me that
- ia32-libs is going away in Oneiric in favor of multiarch
- the multiarch spec does not allow dependencies on packages from a non-native architecture -- you have to manually install said packages in a separate invocation.
This combines to mean that it's impossible to write a metapackage that depends on the libraries we've been wanting to run things out of AFS -- e.g., debathena-athena-libraries can't depend on 64-bit and 32-bit libraries on amd64. At best we can write an arch-dependent metapackage debathena-athena-lib32raries, but none of our other metapackages can depend on that; it'll have to be installed manually.
The right place to figure out what we need to do about this, and possibly what upstream needs to do about this, is #multiarch on OFTC. I'm milestoning this as a Natty Beta blocker because we need to deal really really quickly before Oneiric's multiarch plans are too immutable, even though it doesn't affect the Natty cluster release directly.
References:
https://wiki.ubuntu.com/MultiarchSpec
Pre-multiarch, architecture-dependent packages may depend on Architecture: all packages and assume that the transitive dependencies will be resolved using packages of the same architecture or other packages that are Architecture: all. To avoid breaking this assumption, Architecture: all packages will, at least initially, be treated as equivalent to packages of the native architecture for all dependency resolution. This means that for an Architecture: all package to satisfy the dependencies of a foreign-architecture package, it must be marked Multi-Arch: foreign or Multi-Arch: allowed.
http://summit.ubuntu.com/uds-o/meeting/foundations-o-multiarch-next-steps/
Oneiric goals:
- ia32-libs out of the archive (i.e. multiarch-ify everything in ia32-libs - at least 200 libraries)
- Get rid of lib{32,64}foo
Change History
comment:2 Changed 13 years ago by jdreed
So based on this zephyr discussion, do we still need to panic? Manual installation is not hard, it's one line in the installer.
comment:4 Changed 13 years ago by geofft
- Summary changed from Panic about lack of ia32-libs in Oneiric to Worry about change to ia32-libs in Precise
ia32-libs is back in Oneiric and should be fine (although it's worth checking one last time). Precise is intending to replace it with a transitional package to ia32-libs-multiarch.
comment:5 Changed 12 years ago by jdreed
I'm still not sure what the action item is out of this. "apt-get install ia32-libs-multiarch" works fine on Precise, as does "aptitude install ia32-libs-multiarch". It seems that when debathena-thirdparty-libraries is installed, the ia32-libs recommendation is either not satisfiable or is ignored. I _think_ I blame thirdparty here for making a mess of the dependency resolver.
comment:6 Changed 12 years ago by jdreed
- Milestone changed from Precise Beta to Quantum Quetzalcoatl
I don't think any action is necessary for Precise. I think it will be on quantal, but for now, the various lib32 dependencies in debathena-athena-libraries are still satisfiable on Precise.
comment:7 Changed 12 years ago by jdreed
So, one of the original issues was that ia32-libs does not get installed in Precise. The reason for this is simple: nothing in athena-libraries depends or recommends it. It's unclear _why_ this is the case, though I think I blame the awesome logic in the rules file.
One of the goals of debathena-athena-libraries was to provide as much stuff as needed to run locker software. At this point, I think this should be a statically maintained list, and we should focus on reducing it as much as possible, because it's not 2009 anymore.
That having been said, I do not think "the multiarch spec does not allow dependencies on packages from a non-native architecture -- you have to manually install said packages in a separate invocation" is 100% correct; it seems to conflict with the idea of a package being marked "Multi-arch: foreign", which ia32-libs-multiarch is.
At this point, until we actually figure out what we want, it's probably easy to simply add ia32-libs-multiarch to the installer, and decide that if you're too paranoid to run the installer, you get to figure out locker software dependencies by hand.
comment:8 Changed 12 years ago by jdreed
debathena / trac-#931 / andersk 20:32 (Anders Kaseorg) > Right, so why can't we just Depend: ia32-libs | ia32-libs-multiarch > and be done? We can even just depend ia32-libs and be done. debathena / trac-#931 / andersk 20:34 (Anders Kaseorg) The reason debathena-athena-libraries lost its ia32-libs dependency is just that ia32-libs no longer provides a .shlibs file.
comment:9 Changed 12 years ago by jdreed
- Priority changed from blocker to normal
- Summary changed from Worry about change to ia32-libs in Precise to Try and reduce dependence on ia32-libs
- Milestone changed from Quantum Quetzalcoatl to The Distant Future
We can and will Recommend: ia32-libs in debathena-athena-libraries for the near future. We should still strive to identify and depend manually (possibly with debathena-athena-lib32raries:i386 or something) what we actually care about instead of installing the world.
comment:10 Changed 12 years ago by jdreed
We, uh, should move forward on this. I suspect this involves setting up a VM without ia32-libs, and seeing what is listed in WRW that breaks.
comment:11 Changed 12 years ago by geofft
The ia32-libs in Jessie is only installable if you do a dpkg --add-architecture i386, precisely because (afaict) they're doing the same sort of trick to jump architectures as discussed on this ticket. Ubuntu automatically does that (in dpkg's postinst), and I think is planning to maintain the delta to do that indefinitely. (Also, it looks like Ubuntu is naming the i386-only arch-jumping package ia32-libs-multiarch, and Debian is naming it ia32-libs-i386.)
We might possibly want the Debathena installer to add the i386 foreign arch on Debian systems, and the manual install instructions to mention it.
comment:12 Changed 10 years ago by jdreed
- Priority changed from normal to blocker
- Milestone changed from The Distant Future to Current Semester
OK, ia32-libs-multiarch is now gone in Trusty. We need to deal with this. A lot of i386 libraries are pulled in via our normal dependencies, but we're missing some of them. The easiest way to fix this is probably:
Package: debathena-ia32-libs Architecture: i386 Depends: whatever Multi-Arch: foreign
And then have athena-libraries or something depend on debathena-ia32-libs.
comment:13 Changed 10 years ago by jdreed
- Status changed from assigned to review
comment:15 Changed 10 years ago by jdreed
This mostly works, with the caveat that on do-release-upgrade from precise to trusty, ia32-libs will remain installed on Trusty, and will thus satisfy the disjunction in athena-libraries. Once Precise goes into maintenance mode, we can simply stop building for it, and unconditionally Recommend our -ia32 package. I think Precise's multiarch support is still broken enough that we can't just stop using ia32-libs on Precise.
comment:16 Changed 8 years ago by andersk
- Status changed from development to proposed
- Fixed in version set to debathena-athena-libraries 1.5
comment:17 Changed 8 years ago by andersk
- Status changed from proposed to closed
- Resolution set to fixed
Zephyr discussion indicates that it's possible that creating an Architecture: i386 metapackage called debathena-athena-libraries-i386 that does nothing other than depend on debathena-athena-libraries, and adding "debathena-athena-libraries-i386:any [amd64]" to debathena-athena-libraries' Depends field, is likely to end up with amd64 systems getting both debathena-athena-libraries:i386 and debathena-athena-libraries:amd64, and thus both i386 and amd64 versions of those libraries.