On Thu, Apr 26, 2012 at 23:21, Osamu Aoki <os...@debian.org> wrote: > Hi, > > On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote: >> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote: >> >> > If a package is marked as "Multi-Arch: same", files with the same >> > name have to be (byte-to-byte) identical across all architectures. >> > Unfortunately, not all packages obey this requirement. I set up a >> > page to track violators: >> > >> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt >> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist >> > >> I've just filed a number of bugs (~60) based on this list, excluding >> binNMUed packages and packages affected by #647522. > > Yep, I got it :-) And you answered to my question: > >> > Is there any generic solution for GTK girepository files? >> > >> You should remove the multi-arch: same control field, gir packages are >> not ready for multiarch for now. > > I also see for libopencc1 (not mine but I am watching it...) > > [libopencc1 0.3.0-2] > usr/share/locale/zh_CN/LC_MESSAGES/opencc.mo > 2c2024df5378074f4727948eb7133516 mips s390 sparc s390x powerpc > 6a7df4d7f1f5383bd7461de8a0bb4957 kfreebsd-amd64 i386 armel armhf ia64 > kfreebsd-i386 mipsel amd64 > usr/share/locale/zh_HK/LC_MESSAGES/opencc.mo > 66224514d0c66fd34bfbf95becf8cfd0 kfreebsd-amd64 i386 armel armhf ia64 > kfreebsd-i386 mipsel amd64 > 6c6698b86bbf568baefc414d178108a0 mips s390 sparc s390x powerpc > usr/share/locale/zh_TW/LC_MESSAGES/opencc.mo > a7fe10a01d59cb26825678bb6c9c2402 kfreebsd-amd64 i386 armel armhf ia64 > kfreebsd-i386 mipsel amd64 > d26ada42ce92c0cea19f4705ca89d433 mips s390 sparc s390x powerpc > > I guess the solution should be the same for now. > > For these issies, I wonder 2 things: > > * These generated non-code data which depend on arch need some generic > solution. Is there any wiki-page summarizing these. I understand it > is non-trivial thing and it certainly requires cordinated efforts. > > * If I vaguely remember, I added this for my package due to the lintian > warning. We certainly needs to fine tune text so we do not add > these. > > Osamu >
So we need to revisit the endianness handling in current M-A design. Currently I don't see there are any common way to workaround such problem with Gettext .mo files in a package maintainer's point of view. Even if we have applied workaround for some other data files (install those files under usr/lib/<tripple>), it does not make sense for these .mo files. Splitting the files into another arch:any package without any M-A fields set does not help, because doing such will make the dependent package which has "M-A:same" not co-installable for two or more architectures. -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w7uy76eow6y+-urpzungwo11ndswb9q1t4eorlms8a...@mail.gmail.com
