On 20 April 2014 12:58, Thorsten Glaser <t...@debian.org> wrote: > Stuart Prescott <stuart <at> debian.org> writes: > >> Unfortunately, the people who understand multiarch well enough to write it >> up for policy haven't done so which leaves us with no normative >> documentation in policy for the the Multi-Arch field in Packages, no >> description of how the package manager should deal with multi-arch packages >> and their dependencies and no documentation of best practices for -dev >> packages etc. > > This can be read as "M-A in its current form is RC-buggy and must > not be released". With the obvious follow-ups (revert M-A perl/python > in sid, as Guillem said). >
This is a bit of a stretch. By default Debian systems install a single architecture only, and do not enable foreign architectures. Therefore by default M-A fields and/or :any / :native suffixes make no difference in dependency and build-dependency resolutions. At Debconf 2013 in Switzerland, there was a multi-arch BoF to address "m-a for interpreters" (python, perl, ruby, etc.) and I solid and working plan was designed there and then. The python m-a work pre-dates that BoF, and as soon as more correct strategy is implemented, I'd expect for python to switch. In a way python m-a work was a pilot to find out caveats. As it stands right now, python multiarch work does enable cross-compilation of packages that also compile python extensions. It doesn't help with i want to install $foo:all -> figure out all the right transitive dependencies for either of the arches that i can run. And that's the problem the 2013 BoF has a plan to fix. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANBHLUhOKbAgouDMcR4sjo6=a05aw8y66kswrfjzxpno1ng...@mail.gmail.com
