On Sat, Dec 10, 2011 at 09:59, Osamu Aoki <os...@debian.org> wrote: > 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. >
It's still a remaining problem for discussion because no better solution other than a wildcard is around AFAIK. > > 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 > > Yes, you can get that variable through dpkg-archiecture, but it isn't the correct approach. Because /usr/bin/dpkg-architecture is provided by dpkg-dev, which is not an acceptable dependency for a user-oriented binary package. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
