On Sun, Feb 11, 2007 at 08:23:29PM +0100, Loïc Minier wrote: > Some shared libraries have gettext translations below /usr/share/locale > with the source package name as textdomain. When such a shared lib > changes SONAME, how are you handling it?
> 1) check all strings to see whether there are only additions and no > incompatible changes, and add a Replace: $oldpackage to $newpackage > 2) don't really check, add a replace, and cross your finger that no > format string such as "%s: %s" was changed incompatibly (to "%s: %s > %s" :-) FWIW, this would not result in a format string vulnerability in gettext, because the change to the source format string would also invalidate the translation lookup, so there's simply no risk of this pulling in a wrong format string unless there's a bug in the .po file itself. > 3) patch $newpackage to use a different textdomain > The problem I have with 3) is that it might introduce some > incompatibilities; for example it would break the approach used in the > Ubuntu "language packs" which I think rely on the name of the .mo files > to work. I'm not sure to what extent the translations are part of the > ABI of the library. Well, the translations really should not be part of the ABI of the library; libraries shouldn't be engaging in direct interaction with the user, so the use case for localization of libraries is really limited to interfaces such as strerror() which will localize numeric codes for you. Not sure how that helps you pick a solution from the above, though. 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. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]