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
Attachment:
signature.asc
Description: OpenPGP digital signature