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+deb...@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.
> I believe you are correct that the dependency is too weak. But my
> understanding is that "pkg:<arch>" dependencies are poorly supported.
> Accordingly, I am not sure it is possible to fix this bug at the moment.
> (CC'ing Helmut, whom I hope could remind me if "pkg:<arch>" support is
> good enough to rely on it or if he has a different take on the problem).
Actually, I don't exactly know either. I know some aspects though. Let
me share those.
You should strongly between cross-arch dependencies and same
arch-dependencies. Having Architecture: arch1 and Depends foo:arch2 is
not as well supported as having Architecture: arch1 and Depends:
foo:arch1. For instance, crossbuild-essential-<arch> used to Depends:
libc-dev:<arch>, which is a cross-arch dependency. Here, we are talking
about same-arch restrictions.
In the crossbuild-essential-<arch> issue, I think the problem was
testing migration. The installability checker would flag the dependency
and never let the package pass. If that is correct, it indicates that
what you want to do here, actually works rather well.
Johannes Schauer wrote a tool that can tell you whether dose, dpkg and
apt agree on satisfiability situations. You can find it at
https://gitlab.mister-muffin.de/josch/deb-m-a-dep-check. I believe that
its output would provide a valuable data point here. The tool
systematically constructs artificial packages and asks these resolvers
to check potential installation sets. There were some interesting
differences. I'd avoid situations where different resolvers disagree.
For instance, they disagree about :native annotations on Architecture:
all packages, see #854438. I'm not quite sure whether it handles :<arch>
though.
Hope this helps
Helmut
