[Multiarch-devel] Architecture: all + M-A: foreign

[Steve Langasek]

On Thu, Dec 06, 2012 at 02:05:13AM -0600, Peter Samuelson wrote:

> In bug #695229, I noted that an Architecture: all package really should
> be Multi-Arch: foreign.  This led to an IRC discussion between Goswin,
> Steve L. and me in which I formulated the proposal:

>     If a package is 'Architecture: all', and all its dependencies are
>     'Multi-Arch: foreign' (including the case where there are no
>     dependencies), this package should implicitly be treated as
>     'Multi-Arch: foreign' as well.

> Steve asked what the impact would be, given that Multi-Arch: foreign
> only matters if you have reverse dependencies that are not
> Architecture: all.  So I wrote a crude script to figure it out.  The
> numbers depend on whether you consider only Depends + Pre-Depends, or
> if you also consider Recommends and Suggests.

>                                Explicit M-A:foreign | Implicit M-A:foreign
>                               +---------------------+---------------------
>                               |                With |                With
>                       | Total |   All  non-arch:all |   All  non-arch:all
> Rule variant          |       |          rev-dep(s) |          rev-dep(s)
> ----------------------+-------+---------------------+---------------------
> Depends + Pre-Depends | 17339 |   580           145 |  5310           994
> Dep + P-D + Rec + Sug | 17339 |   580           197 |  2969          1151

> Now, whether to consider Recommends and Suggests in the calculations, I
> don't have a strong opinion.  It does change the mix of packages.  For
> example:

> - bash-completion could be implicitly M-A:foreign, but this only really
>   "matters" if we consider Recommends + Suggests.  Almost nothing
>   Depends on it, but several arch:any packages Recommend or Suggest it.

> - aptitude-common is implicitly M-A:foreign only if we do _not_
>   consider Recommends + Suggests, because while it has no dependencies,
>   it Recommends aptitude, which is not M-A:foreign.

> - alsa-base is implicitly M-A:foreign only if we do _not_ consider
>   Recommends, because while it only Depends on packages which are
>   M-A:foreign, it Recommends alsa-utils, which is not.

In practice, I think you actually want to distinguish between the
recommends/suggests of an arch: all package, and arch: all packages that are
recommended/suggested.  The scenario that led to arch: all packages *not*
being considered inherently Multi-Arch: foreign was:

  - package A requires functionality from package C or package D
  - package C/D must be of the same arch as package A
  - package B is architecture: all and depends on one of C or D, selecting
    which implementation to expose
  - package A depends on B to express its requirement

(i.e.: package python-foo Depends: python Depends: python2.7)

When either relationship is weaker than a Depends, the first of these
conditions, "A requires functionality from package C or package D", cannot
be true, so it's not actually necessary to solve it.

Thus, when considering whether a package being implicitly M-A: foreign would
*break* the reverse dependencies by violating the expectation that A and C/D
will be of the same architecture, we only need to consider the depends and
pre-depends of package B.  But when considering whether it's *useful* to
promote B to be implicitly M-A: foreign, we should look at (at least) the
reverse-recommends as well, since a foreign-architecture package which
Recommends: B will have this recommendation ignored by the package manager
as unsatisfiable if B is not M-A: foreign, but will cause B to be installed
if it is M-A: foreign.

For the concrete examples you've given, it would be safe and (at least
potentially) useful for each of bash-completion, aptitude-common, and
alsa-base to be M-A: foreign, whether that's done explicitly or implicitly.

> Anyway, these numbers indicate to me that it may be worth patching
> dpkg, apt, aptitude and other deb + multi-arch aware tools, to
> implicitly mark all those Arch:all packages as Multi-Arch:foreign, so
> that this doesn't have to be done explicitly.

> (But not during the freeze.)  Thoughts?

Given that this package manager change won't happen it time for wheezy
(which I agree with), it might be worth considering whether we could instead
solve all the real instances of A->B->C/D in the archive by converting all B
to Arch: any in wheezy, and then just allowing the package manager to treat
*all* Arch: all packages as implicitly satisfying foreign-arch deps in
jessie.  Because the standard example here, python, does actually need to be
made Arch: any instead of Arch: all to satisfy certain constraints for
cross-compiling (a change which is already implemented in Ubuntu and AIUI is
planned for experimental soon), it's possible that we could make all this
complexity and confusion go away within the space of an upgrade cycle
without having to add non-local dependency traversal to dpkg.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/multiarch-devel/attachments/20121208/0d80fd5e/attachment.pgp>