Goswin von Brederlow wrote: > pkg:arch will still be unique and the dpkg/apt output will use the > architecture where required for uniqueness. So I think that after some > getting used to it it will be clear enough again.
Here are a few examples of the problems I worry about. I have not verified any of them, and they're clearly biased toward code I am familiar with, which suggests there are many other similar problems. * Puppet not only installs packages, it may remove them. A puppet config that does dpkg --purge foo will fail if multiarch is enabled, now it needs to find and remove foo:* * dpkg-repack pkg:arch will create a package with that literal name (or fail) * dpkg-reconfigure probably can't be used with M-A same packages. debconf probably generally needs porting to multiarch. * tasksel uses dpkg --query to work out if a task's dependencies are installed. In the event that a library is directly part of a task, this will fail when multiarch is enabled. * Every piece of documentation that gives commands lines manipulating library packages is potentially broken. Seems like we need a release where multiarch is classed as an experimental feature, which when enabled can break the system. But the sort of problems above are the easy to anticipate ones; my real worry is the unanticipated classes of problems. Especially if we find intractable problems or levels of complexity introduced by dropping the unique package name invariant. My nightmare scenario is that we release with multiarch, discover that it's a net negative for our users (proprietary software on amd64 aside, nearly all the benefits are to developers AFAICS), and are stuck with it. -- see shy jo
signature.asc
Description: Digital signature
