Hi Goswin, hi -devel, I would somewhat object to Multi-Arch field in the long run, and here are my thoughts.
What the multiarch spec proposes now is package-oriented approach: the package should define whether it is 'same' or 'foreign' kind. This is not straightforward, because in fact not the package decides it's multiarch 'role', but its reverse dependencies. Only they 'decide' they want to arch-dependent package 'functionality' or arch-independent one. From the package manager PoV (dpkg and its frontends) I find dependency-oriented multiarch info is more clearer and easier to implement. Goswin, as you are already noted, the packages which are known to have both kind of dependencies - at least, some interpreters - have nothing to do with that Multi-Arch field, and to handle them, you'll have to put this info in the package that is dependent on this interpreter in the long run. Moreover, this is not the only exception. Thousands of desktop and server packages that contains executable binaries (applications) compiled from C/C++/Pascal/etc. also have arch-dependent reverse dependencies - packages with debug info, '-dbg' ones. So, they are not 'Multi-Arch: foreign' too. With 'arch:all' packages being not a problem at all fortunately, there are only one (?) kind of packages left with meaningful Multi-Arch fields - arch-dependent library packages for compiled languages which are always multiarch 'same', but they also already special-cased/handled by various tools like dpkg-shlibdeps, dpkg-genshlibs, and it would been possible to even generate runtime dependencies ({shlibs:Depends}) with proper multiarch dependency info without even bothering the maintainer to do it. For the upgrade path, we can stick default multiarch 'same' to the all packages in archive, so implementing multiarch support won't broke anything at all at all without changing nor source not binary packages at this moment, and the maintainers are free to bother ourselves to mark some dependencies as multiarch 'same' to allow foreign dependencies to be satisfied with less number of packages in the system in the long run. -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Maintainer
signature.asc
Description: OpenPGP digital signature