[Pkg-ime-devel] Bug#651488: Bug#651488: support Multi-Arch
Osamu Aoki
osamu at debian.org
Sat Dec 10 01:59:42 UTC 2011
Hi,
Thanks. Your reply solved all my qestions but caused one more question
to fix another bug.
On Fri, Dec 09, 2011 at 08:44:38AM -0800, Kees Cook wrote:
> Hi Osamu,
> > #Q3 do we need to hardcode exact $DEB_HOST_MULTIARCH as below. What is
> > the negative of just using * for those location as below?
>
> The problem comes when multiple architectures are installed on the system,
> or potentially, only the non-native version is installed. In which case "*"
> would match it, but not actually be available. Since the xinput.d script
> runs only for the native system, it needs to examine its environment from
> only the native library perspective. At least that is my understanding of
> the logic in that script.
That was my thought too. Good. I do not expect this to be high risk
but why not do it this way, since ibus is an arch any package,
$DEB_HOST_MULTIARCH can be hardcoded in for im-switch.
This means im-config should do the same to be safer but how to do the
same for im-config which is an arch all package.
FYI: I am deprecating im-switch and pushing im-config. im-switch is
over engineered and harder to extend to support cases like requiring 2
independent packages for activating IM (GTK2+GTK3). The only negative
of im-config is that its driving data are all in one package so
maintainer has to fix for every IM. But this negative can be sais as
positive of good consistency.
I guess I need to set it in the run time using $DEB_BUILD_MULTIARCH or
$DEB_HOST_MULTIARCH ?
Since $DEB_HOST_MULTIARCH seems for target machine, $DEB_BUILD_MULTIARCH
seems to be the right choice to know from the native library perspective
in run time.
To get this, is the use of dpkg-architecture best way or simpler way.
Osamu
More information about the Pkg-ime-devel
mailing list