tag 545464 - patch thanks The plan for the transition will be: 0. fix dpkg-cross to properly create the packages that should have been made in the latest release. 1. dpkg-cross puts no files in the new multiarch locations, no matter what - this prevents conflicts when the new version of dpkg is able to install the packages containing those multiarch locations. 2. dpkg-cross enforces OLD behaviour for all packages no matter what - this preserves the old paths for the current compilers. 3. packages that contain multiarch metadata in debian/control get an explanation in the -cross package description and that's it - these are henceforth termed zombie cross packages because they are only needed to support remaining reverse dependencies. 4. need am emprunecross helper to identify these zombie cross packages and delete them all. (emprunecross removes all -cross, the new helper needs to be in dpkg-cross and far more precise.) 5. need zombie package-aware dpkg-checkbuilddeps 6. At some point *AFTER* dpkg has support for installing the true multiarch packages in their correct (new) locations (e.g. usr/lib/$triplet), then a new version of dpkg-cross can be prepared that drops the old location from any new zombie packages created after that time. All zombies (and only zombies) will be made from multiarch-compatible packages and zombies created by the final version of dpkg-cross will be truly empty. Item 5 will wait, the important parts are: a: current compilers work with current locations and gradually learn to look in the new multiarch locations - packages or test chroots can be manually fettled to have files in the relevant locations for testing purposes. Alternatively, test with a patched dpkg that can use the multiarch package itself. b: when a version of dpkg is uploaded that understands how to install an armel mulitarch package alongside the amd64 one, the cross package will not prevent installation of the armel mulitarch package. c: The aim is to have the wrapper for removing these zombie packages in the version of dpkg-cross which makes it into Squeeze. Users are advised to run the wrapper frequently to reduce problems of having a new version of the headers in the multiarch location and a previous version in the old cross location. It is not possible to impose a arch-specific conflict in the zombie cross package but it might be possible for the multiarch package to conflict with the zombie cross package. d: the patch for #545464 is wrong because it puts symlinks in the new location and the real files in the old location. This is unnecessary churn when this zombie cross package merely needs to contain the files for the old location and be deleted as soon as the reverse dependencies make that possible. e: if this all happens during a SONAME transition for a particular package all bets are off - although it probably will work as the zombie cross package will replace the previous cross package with the new version headers. f: essentially, the perennial problem of not being able to automatically upgrade -cross packages remains as problematic as ever because of #d and #e. The intention here is to not require a new version of dpkg-cross immediately that a new version of dpkg becomes available and to be sure that the new version of dpkg can install multiarch packages without dpkg-cross and -cross packages in general getting in the way. There was always going to be some pain during this transition for those who want to use dpkg-cross with Debian unstable (or squeeze until the freeze starts) - that pain is mostly restricted to manually having to update and upgrade -cross packages but as this burden is not new, I don't see that as a barrier. It just becomes possibly more of an issue than previously. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp6fGO2qfrsP.pgp
Description: PGP signature