On Tue, 2008-09-09 at 11:03 +0200, Sven Joachim wrote: > On 2008-09-09 10:27 +0200, Neil Williams wrote: > > > The package supports a method of adding unsupported locales but that > > this method does not appear to have been used. > > > > Unless the submitter can demonstrate that the existing support is > > broken, I think this bug should be downgraded to normal. > > > > It seems reasonable to me that a package can drop configuration values > > that are unsupported by the package - especially if the package does > > have a way of extending support to meet particular needs. > > Unless /usr/locale/share/i18n/SUPPORTED can be shown to be broken, I > > don't see a bug here - except maybe a wishlist one for the maintainer > > script to explain what it has done or some comment in README.Debian > > about how to use /usr/locale/share/i18n/SUPPORTED (especially as that is > > a rather strange path - I was expecting /usr/share/locales/SUPPORTED or > > something similar). > > For the record, the path is /usr/local/share/i18n/SUPPORTED (not > /usr/locale/...), and that seems perfectly reasonable, since you don't > want to edit files under /usr locally. In that case, the bug is a documentation bug for /etc/locale.gen which contains: # This file lists locales that you wish to have built. You can find a list # of valid supported locales at /usr/share/i18n/SUPPORTED, and you can add # user defined locales to /usr/locale/share/i18n/SUPPORTED. If you change # this file, you need to rerun locale-gen. (That is where I looked for the path). /usr/local/share is fine, I agree - just that this bug may turn out to be little more than a typo. Would you agree that the severity should be lowered? -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part