Hi,
I looked into this again. Pulling in multiarch-devel@l.a.d.o because
this is kind of a general issue.
On Mon, Jun 25, 2012 at 12:46:16AM +0200, Carsten Hey wrote:
> weasel noted that tor-dbg exists and depends on tor. Since dpkg
> currently handles arch all packages as if they were native for
> dependency resolution [1], this leads to this situation:
>
> * tor-dbg requires tor to be installed for the same arch as tor-dbg.
Can you give a technical reason for this? Why would taking a core file
on a different system and debugging it with just the tor-dbg image using
gdb-multiarch not work?
Indeed it should be possible to turn tor-dbg into Multi-Arch:same with
some more effort (i.e. not for wheezy).
> According to [2] and in theory, the fix for this bug is:
>
> Package: tor
> Architecture: any
> Depends: ...
> Multi-Arch: allowed
We should notice that Multi-Arch:allowed was not intended for this case.
"Abusing" allowed here just for a debug dependency sounds just wrong.
So what are other packages doing?
avahi-daemon is M-A:foreign. avahi-dbg has no dependencies.
bluez is M-A:foreign. bluez-dbg depends on bluez (= ${binary:Version}).
cmake is M-A:foreign. cmake-dbg depends on cmake (= ${binary:Version}).
cups is M-A:foreign. cups-dbg depends on cups (= ${binary:Version}).
daisy-player is M-A:foreign. daisy-player-dbg depends on daisy-player
(= ${binary:Version}).
dbus is M-A:foreign. dbus-1-dbg depends on dbus (= ${binary:Version}).
e2fsprogs is M-A:foreign. e2fsprogs depends on e2fsprogs
(= ${binary:Version}).
ebook-speaker is M-A:foreign. ebook-speaker-dbg depends on ebook-speaker
(= ${binary:Version}).
espeak is M-A:foreign. espeak-dbg depends on espeak
(= ${binary:Version}).
ghostscript is M-A:foreign. ghostscript-dbg seems to be a cumulative
debug package. One alternative of the dependencies is ghostscript
(= ${binary:Version}).
gpsd is M-A:foreign. gpsd-dbg seems to be a cumulative debug package.
One alternative of the dependencies is gpsd (= ${binary:Version}).
imagemagick is M-A:foreign. imagemagick-dbg depends on imagemagick
(= ${binary:Version}).
I believe we can already spot a pattern. Debug packages tend to depend
on M-A:foreign packages. This does not seem like the ultimately best
solution, but a reasonable compromise for the time being.
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
