Hi,

I have BCC'ed debian-devel on this email to ask for input on this bug
(#903158) and ask parties that are interested to follow up there. I am considering to remove the dependencies for -dbgsym packages on the
grounds that:

1) They are too weak when M-A: foreign is involved and they are not
always help (see the partial email quote from the bug below)
2) We now have a debuginfod service, so you do not even have to install
dbgsym packages anymore (if you configure gdb to use it). For the
cases where you do install the dbgsym, you still have to manage
inter-source dbgsym dependencies manually.

As a debhelper maintainer, I willing to either keep the status quo and
close the bug as wontfix or close the bug by removing the dependencies.
If you hoping for another outcome, I expect you to be ready to put the
effort and patches required to reach the outcome.

Thanks,
~Niels

On Sat, 4 Aug 2018 21:04:59 +0200 Helmut Grohne <helmut@subdivi.de> wrote:

Hi Niels,

On Sat, Aug 04, 2018 at 08:38:00AM +0000, Niels Thykier wrote:

On Sat, 7 Jul 2018 11:40:54 +0300 "Yuriy M. Kaminskiy" <yumkam+debian@gmail.com> wrote:

I think (at least, 'Multi-arch: foreign' *and* 'Architecture' != all) packages should have explicit parent package arch dependency
Depend: foo:${Arch} (=${binary:Version})
instead of
Depend: foo (=${binary:Version})
Untested patch against debhelper 11.3.5 attached (please review carefully, I'm neither M-A nor debhelper expert).

Yes, this makes somewhat sense.

Personally, I disagree with the Depends though. I've often been in the situation of wanting to debug a foreign core file or remotely attaching
to a process on a different system. These dependencies were not helpful
at all in these situations. Personally, I'm in favour of making -dbgsym packages dependency-less. I acknowledge that others see things
different.

In any case, we agree that if we want the dependency, then it is
presently too weak.

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Oct 08, 2022 at 03:42:59PM +0100, Simon McVittie wrote:

I was under the impression that the Debian archive does not allow dependencies with an explicit architecture like this, only the :any
qualifier for M-A: allowed packages (like python3:any).

"allow" is a strong word especially if you don't find it in policy
(but then, policy documents existing usage, so some usage pre-dates
policy by definition I guess).

It is also not really related to MultiArch ipso facto as the initial
spec explicitly mentions it as a dropped discussion point. [0]
It was later added with MultiArchCross [1] with the previously mentioned caveats still in place as cross-building is not a thing in the archive
(as we build everything natively – ignoring special cases like win32).

That said, we have some packages declare cross-architecture dependencies
in the archive (even in stable), but not as a hard-dependency as indeed
various archive tools can not deal with such dependencies and its
unclear if they even should as MultiArch is not a default configuration.
(which I want to highlight explicitly here as it is frequently compared
to things we ship or enable by default for everyone)

Examples are:
- crossbuild-essential-i386 depends on gcc-i686-linux-gnu | gcc:i386
- gamemode recommends libgamemode0:i386
- libc6-i386 conflicts with libc6-x32:i386

(and that is just looking at :i386 in amd64 as that is a somewhat common
usage to bring in i386 packages on amd64.)

The trick previously was to depend on a package only available in the
other architecture, which equally doesn't work with tools who only have
a single arch available and is less obvious for the casual on-looker.


apt (and libapt-based friends) and dpkg agree mostly on what things mean
and if they don't it tends to be way beyond the pay grade of the average
DD (an example would be #770345 that is have left hanging for 8 years
now) – no disrespect intended! It is just that I would certainly not
want to reason about any of that stuff if that wouldn't come hand in
hand with being an apt dev… bringing all those nitty-gritty details to
policy would certainly be an interesting endeavour but if it would
really be a service to human kind^W^Wcontributors I am not so sure even
if its frequently used as an argument against MultiArch and related
projects.


Best regards

David Kalnischkies

[0] https://wiki.ubuntu.com/MultiarchSpec#Allow_official_packages_to_have_cross-architecture_deps
[1] https://wiki.ubuntu.com/MultiarchCross#Cross-architecture_dependencies

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmNDJKgACgkQMRvlz3HQ eIPoxA/9FmcbxR3/hS44rYVQuWxLWUi89/5XFgrUBgaaU7q0B5hnADYFqVk5PkIy umlL1+tx+0qPnfrg87AsDLHYhCpuwg1AnIIADa4Rc6L4kdCK6d5Nt7Fe6abGXVZd lOocXf3aXLekVDFmf8H+7DMuIBZNJiMSjXBIHgnaZNIDuONxjvM7nGuyJjvNSekQ o/OSFlxJ7CsVnICkaLEpf6jzjvEbWshz4O92MhTLkXpFqwjrXy2mm/bmYozXV4Oj UAzVTP7g04YMNNGkfcHt5DQIXYhTFQyvNbmJk//oiFYUlnsJ70HOpZYFZJ6NZFCF RaQ6sU4/nLT6WV0uh/UwFMy4nRiDMD1BhXk2bm13oHwuMXEqYI38T+tByY30qJJu 6bIODEXGTQzks7w+1arqvKxG/jY60xl0oDQr6zpwhYmR6iT56iyPjytYpYQk3HJI s2WWIwYnP65uIWw0atjwOqvZJ+M26nELhdkFMCZbIw23FJOmE3N6mz+tyGu3mMKy gW3zGn1Tah3dRgsvq5LhTRU0Zm4G3MdagsGk9iueird1g8ijP1s/OkWW/IuEa8RB 0e4MFUGq22oqtynGe8CvmzONqlA3WK+ELeiLZjbBFuoB8la4FPR8+0yBFRrRPuwz DPSZjg4swgTnA2/Af1+0dH0SfNQVUtUgfRWdsiIWJM5Zfp9PL44=
=I54L
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)