Bug#676653: tor: please add Multi-Arch: foreign to the tor package
Hi, what's the current status of setting tor to Multi-Arch: foreign? Or allowed? - wheezy is released, jessie has packages with M-A:allowed and :any dependencies, if needed. - Some tooling for automatic -dbgsym packages is in place (haven't looked at it yet...). I think, I have even seen something in backports. Cheers Elrond
Bug#676653: [Multiarch-devel] Bug#676653: tor: please add Multi-Arch: foreign to the tor package
(I wish we could just have automated debug packages and don't have to
worry about this... :/)
* Helmut Grohne hel...@subdivi.de, 2013-01-09, 09:53:
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?
Are you saying that tor-dbg should not depend on tor at all?
Well, that's not unreasonable, but that's also not what we've been
historically doing with -dbg packages[0].
But _if_ tor-dbg is supposed to depend tor, then marking tor as
MA:foreign is clearly wrong.
Indeed it should be possible to turn tor-dbg into Multi-Arch:same with
some more effort (i.e. not for wheezy).
True, but I don't see how is this relevant for the problem at hand.
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.
It doesn't to me.
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.
I can see a pattern of bugs. :)
[0] http://lintian.debian.org/tags/dbg-package-missing-depends.html
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676653: tor: please add Multi-Arch: foreign to the tor package
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
Bug#676653: tor: please add Multi-Arch: foreign to the tor package
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: Oh right. Thanks for looking into the details that I missed. In practice, I think delaying this for after Wheezy as you suggested is the way to go because: ... * :any is currently neither used in Ubuntu nor in Debian. Introducing the first package with such a dependency a week before the freeze even though it is known to break existing tools would hardly be sane. Right. :any dependencies must not be introduced in wheezy, because the squeeze apt does not know about them and would fail to upgrade. Please delay working on this bug. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676653: tor: please add Multi-Arch: foreign to the tor package
Helmut Grohne schrieb am Freitag, dem 08. Juni 2012: The tor package seems to provide an architecture independent interface (i.e. command line and architecture independent network protocols such as socks and ssl). As such it should be marked as Multi-Arch: foreign. In practise that would allow installing the following combination of packages: dpkg:amd64 tor:i386 tor-geoipdb. This set is currently not installable, since the tor dependency on tor-geoipdb needlessly enforces that tor uses the same architecture as dpkg. The impact of that change, or why it is even needed, is not entirely obvious. Maybe I'll look at this for after wheezy. Cheers, -- | .''`. ** Debian ** Peter Palfrader | : :' : The universal http://www.palfrader.org/ | `. `' Operating System | `-http://www.debian.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676653: tor: please add Multi-Arch: foreign to the tor package
* Peter Palfrader [2012-06-24 15:34 +0200]:
Helmut Grohne schrieb am Freitag, dem 08. Juni 2012:
The tor package seems to provide an architecture independent interface
(i.e. command line and architecture independent network protocols such
as socks and ssl). As such it should be marked as Multi-Arch: foreign.
In practise that would allow installing the following combination of
packages: dpkg:amd64 tor:i386 tor-geoipdb. This set is currently not
installable, since the tor dependency on tor-geoipdb needlessly enforces
that tor uses the same architecture as dpkg.
The impact of that change, or why it is even needed, is not entirely
obvious.
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.
* tor-geoipdb:all should be happy with tor installed for any arch, but
currently depends on tor on the native arch.
According to [2] and in theory, the fix for this bug is:
Package: tor
Architecture: any
Depends: ...
Multi-Arch: allowed
^^^
Package: tor-dbg
Architecture: any
Depends: tor (= ${binary:Version}), ${misc:Depends}
Package: tor-geoipdb
Architecture: all
Depends: tor:any (= ${source:Version}), ${misc:Depends}
In practice, I think delaying this for after Wheezy as you suggested is
the way to go because:
* debfoster and presumably other programs have no idea about the arch
suffix :any.
* :any is currently neither used in Ubuntu nor in Debian. Introducing
the first package with such a dependency a week before the freeze
even though it is known to break existing tools would hardly be sane.
Regards
Carsten
[1]
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages
[2]
https://wiki.ubuntu.com/MultiarchSpec#Extended_semantics_of_per-architecture_package_relationships
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#676653: tor: please add Multi-Arch: foreign to the tor package
Package: tor Version: 0.2.2.36-1 Severity: wishlist The tor package seems to provide an architecture independent interface (i.e. command line and architecture independent network protocols such as socks and ssl). As such it should be marked as Multi-Arch: foreign. In practise that would allow installing the following combination of packages: dpkg:amd64 tor:i386 tor-geoipdb. This set is currently not installable, since the tor dependency on tor-geoipdb needlessly enforces that tor uses the same architecture as dpkg. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
