Re: Architecture: all + M-A: foreign
Hi!
On Thu, 2012-12-06 at 02:05:13 -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.
The issue with arch:all packages goes deeper than that, while going
over the “multiarchification” (starting at [0] and continuing in [1],
broken due to new month archive), I realized that considering arch:all
packages equivalent to native architecture makes this impossible (?)
(I assume this to be the same for python).
[0]: <https://lists.debian.org/debian-perl/2012/11/msg00046.html>
[1]: <https://lists.debian.org/debian-perl/2012/12/msg00000.html>
Consider a perl script (arch:all) that depends on another perl module
(arch:all) and two XS modules (arch:any), if those need to be
co-installable, because they might be needed by a linked program
(arch:any through libperl), then that means the XS modules cannot be
marked M-A:foreign, as they would need to be M-A:same.
Considering arch:all packages == arch:native has the problem of making
some packages not cross-gradable. But making them able to depend or be
depended by any architecture, might imply in some conditions a broken
installation, like the aforementioned XS modules case (as the “wrong”
architecture might end up satisfying the dependency), *but* this is
not a problem with that package being arch:all! it's a problem of the
implicit relationship between the perl interpreter and the XS module,
so this alone still does not solve the “multiarchification” of
perl/python, but it would go a step further in making it possible.
Other things would be needed as I pointed out in [1].
If we'd change the satisfiability on one of the directions of arch:all
packages, I think it would make most sense, at least for consistency
sake, to change both.
> 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.
Given the above I've been pondering (in the thread [0] and [1]) that
we do need to treat them as truly architecture independent, even on
dependencies (in any direction). That's actually something we already
had in mind when discussing the spec, but decided to leave out for
now because it could pose unforseen problems initially or present
“strange” dependency chains proposed by frontends, and it's something
that could always be loosened up later on.
But the thing is, if they are really architecture indendent and as
such their inbound and outbound direct interfaces are only through
architecture independent means (execve(2), shell command invocation,
script loading, etc); then the arch:all == arch:native restriction is
completely artificial, needing to mark all of them as M-A:foreign is
just pointless, «pkg:amd64 → pkg:all → pkg:i386» type of chains should
really be fine, and the frontends should just not propose such solutions
if not asked explicitly.
Thanks,
Guillem
Reply to: