Re: Need help fixing failing locale tests

On 11/15/2015 2:04 PM, Andrey Chernov wrote:
> On 15.11.2015 16:00, Baptiste Daroussin wrote:
>> On Sun, Nov 15, 2015 at 03:56:26PM +0300, Andrey Chernov wrote:
>>> On 15.11.2015 15:46, Baptiste Daroussin wrote:
>>>> On Sun, Nov 15, 2015 at 03:24:19PM +0300, Andrey Chernov wrote:
>>>>> On 15.11.2015 10:09, John Marino wrote:
>>>>> ISO8859-1 locales are legacy even if obsoleted in modern world (I agree
>>>>> with that). Lots of ports (even at configure stage!) have checks for
>>>>> them. Since we generate locales from CLDR now, it will be no cost to
>>>>> bring all 8859-1 back to not violate POLA and not fix every failing port.
>>>>>
>>>> Exp-run have been made and no ports were failing with the removed locales.
>>>
>>> There is soft-fail, configure just marks that locales are not supported
>>> and use "C". Sorry I don't remember port names where I saw it right now
>>> and don't have a time to search for them right now too. Soft-fails (like
>>> in tcl with nl_langinfo) are almost impossible to detect excepting
>>> specific situation happens or source code inspection. Do we ever need
>>> them when there is no harm to keep 8859-1 locales?
>>
>> Is it ok if I readd those locales as aliases on 8859-15?
> 
> It is hacking solution leads to wrong collating order and character
> classes. It is better to generate true 8859-1 just in the same way you
> already do for 8859-15.
> 
> BTW, I can't check right now, but in case 8859-5 is removed too, it is
> better to restore it, it was used in Suns as their standard Russian
> encoding.
> 

DragonFly:

muscles# locale -a | grep 8859-5
uk_UA.ISO8859-5
be_BY.ISO8859-5
ru_RU.ISO8859-5
sr_Cyrl_RS.ISO8859-5

I agree that if -1 is brought back, it needs to be changed at the
charset.xml level.  At that point FreeBSD and DragonFly will diverge.  I
also agree using ports as justification for keeping -1 in western europe
is invalid (as in, it's not causing problems in ports)


John