Andreas Barth <a...@not.so.argh.org> writes: > * Steve Langasek (vor...@debian.org) [090809 21:04]: >> The fallback would be to /assume/ they exist, and >> have each multiarch library package add Conflicts against the expected >> biarch package name; I don't accept that this is an appropriate burden to >> impose on individual library maintainers as part of the multiarch >> implementation, which should otherwise only require a small debian/rules >> change and a single Multi-Arch: yes field. > > Can't that conflicts generation added in some debhelper-rule (same for > cdbs), which puts away the burden from most maintainers? > > > > Cheers, > Andi
Maintainers are burdened with having to Conflicts/Replaces with: Package Popcon count ia32-libs 7273 ia32-libs-dev 1 ia32-libs-gtk 4047 ia32-libs-kde ??? ubuntu ia32-libs-scim ??? ubuntu ia32-libs-xulurunner 1408 ia32-libs-libnspr4 1263 ia32-libs-libnss3 1257 ia32-libs-libssh2 1238 ia32-libs-libidn11 1231 ia32-libs-libcurl3 1221 lib32* On the other hand, assuming that an ia32-apt-get user will keep using ia32-apt-get, the ia32-libs-tools generated packages will take care of themself: 1) The generated packages can trivially conflict with the multiarch packages as soon as dpkg understands the syntax. 2) If ia32-apt-get is used then it sits between the Packages.gz file being downloaded and it being parsed by apt. It could esily add Conflicts/Replaces entries in the multiarch packages on the fly the same way it transforms Packages.gz now. Users would just have to use ia32-apt-get long enough to replace all ia32-* packages with their multiarch equivalent. 3) As mentioned in another mail my plan is to mirror package names multiarch will use them when dpkg/apt support them. The converted packages, always being a lower version than the input package, are then natural predecesors of the multiarch packages and apt will just update it like it updates foo 1.2-3 to foo 1.2-4 now. In effect ia32-libs-tools will generate multiarch packages on the fly. 4) In recent versions all converted packages have "Provides: ia32-abi". If need be (all the above are unsatisfactory) the mutliarch dpkg can conflict with that causing them all to be removed in a single stroke. Users can then reinstall the multiarch ones without problems. The ia32-libs* packages can also Conflicts/Replaces: ia32-abi to allow users to switch between the two methods at will. I don't believe asking ia32-apt-get users, which are officially all unstable users, to run "ia32-apt-get update; ia32-apt-get install ia32-apt-get; ia32-apt-get update; ia32-apt-get dist-upgrade" (or their frontend of choice) before switching on multiarch in apt/dpkg is a burden. For most people that will happen naturally anyway. There is also the issue that it has been around for 1 1/2 years and is in use by a sizeable group of users already. There is no going back, only forward. MfG Goswin -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org