On Wed, May 02, 2012 at 10:23:41PM +0200, Santiago Vila wrote: > I think including .mo files in a library package is wrong by itself, > with or without multiarch, because the next sonme bump will force > the new library package to conflict the old one, which is contrary > to the general design of libraries where you are normally allowed to > install as many different versions of a library as you need without > conflicts.
As a counterexample, please see the apt library packages: $ dpkg -L libapt-inst1.3 | grep 'es.*\.mo' /usr/share/locale/es/LC_MESSAGES/libapt-inst1.3.mo $ You can't safely assume that libraries of different sonames can share the same messages anyway; if a new version of the library has dropped a certain string, and the old version of the library is still installed, trying to share the .mo file would mean the old string is untranslated. I think this is the correct way to handle translations for libraries in nearly all cases, and libc is an exception because of the extraordinary committment to never change the ABI. So yes, keeping the .mo files in the shared library package is otherwise sensible, and it would be preferable to avoid splitting out a -common package just for the translations. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
