Re: Multiarch hinter error? depends is not Multiarch same or foreign
Hi,
I'm sorry that it has taken so long for me to answer this. You shall see
why.
On Thu, Dec 16, 2021 at 11:37:42AM +0800, xiao sheng wen(肖盛文) wrote:
> I'm the maintainer of the stardict pakcage.
>
> I find stardict has Multiarch hinter
> <https://wiki.debian.org/MultiArch/Hints>:[1]
>
> Multiarch hinter <https://wiki.debian.org/MultiArch/Hints> reports 3
> issue(s) normal
> There are issues with the multiarch <https://wiki.debian.org/MultiArch>
> metadata for this package.
>
> * stardict-plugin-cal could be marked Multi-Arch: same
> <https://wiki.debian.org/MultiArch/Hints#ma-same>
> * stardict-plugin-fortune could be marked Multi-Arch: same
> <https://wiki.debian.org/MultiArch/Hints#ma-same>
> * stardict-plugin-info could be marked Multi-Arch: same
> <https://wiki.debian.org/MultiArch/Hints#ma-same>
>
> These three packages depend stardict-gtk which is Multi-Arch: no.
>
> Is this error of Multiarch hinter same for these packages?
This is part of a long-standing disagreement between the hinter and
lintian. I have now (a few days ago) resolved it in the hinter in favour
of lintian's point of view.
Those stardict plugins are technically valid candidates for marking them
Multi-Arch: same. Doing so will not break anything (beyond making
lintian complain). However, you figured that doing so also is useless.
Since their dependency is not (and cannot be) Multi-arch same or
foreign, those plugins cannot ever benefit from being marked Multi-Arch:
same.
I've updated the hinter to no longer emit such hints (where a dependency
lacks an annotation).
So why did the hinter emit such hints? A very frequent pattern is a
shared library and the accompanying lib*-dev package. Assume that none
of them is Multi-Arch marked and that their contents already use
multiarch paths. With the new scheme of things, the hinter will only
report the shared library package and not report the lib*-dev package,
because its dependency is not marked. Then once you mark the library, it
would emit the secondary hint on the lib*-dev package. To avoid this
multistep process, the hinter emitted them all in one go even if some of
them would not be exercisable.
It seems like most people prefer the slow multi-step path, so that's
what the hinter will do now. stardict doesn't receive any hints anymore.
The underlying changes to the hinter were not entirely trivial, which
somewhat explains the delay. Thank you for your patience.
Helmut
Reply to: