После апгрейда mysql-4.1.14 на mysql-4.1.14-r1 напрочь отваливается русский!

Откат на 4.1.14 помогает, но сделать его проблематично по двум причинам:
во-первых этот ebuild уже удалён из portage (т.к. 4.1.14-r1 одновременно
является security fix-ом для 4.1.14), а во-вторых "отваливание русского"
это не баг в 4.1.14-r1 и не фича а багфикс - т.е. во всех последующих
версиях русский сам по себе не появится.

Этот "багфикс" заключается в том, что до этого момента, по ошибке, при
компиляции mysql в нём прошивался дефалтовый charset latin1 вместо utf8.
Что, вероятно, мешало работать utf8-приложениям и вообще не правильно с
точки зрения разработчиков mysql. Для меня лично не совсем очевидно
почему у SQL-сервера вообще должен быть дефалтовый charset задаваемый при
компиляции, и почему это должен быть utf8, в частности... но это лирика.

Итак, у mysql изменился дефалтовый charset. При этом, надо отметить, в
базах на диске по-прежнему остался старый charset. Более того, у каждой
таблицы теперь (начиная с 4.0 или 4.1, не помню) есть свойство charset,
так что mysql даже знает, что в базах всё хранится по-прежнему в latin1.

Проблема заключается в том, что хотя в базах latin1, подконнектившиеся
клиенты теперь работают в utf8, т.е. всё что mysql считывает из базы в
latin1 он пытается перекодировать в utf8, а то, что мы отправляем в него
из клиента sql-запросами (вообще-то это даже не latin1 а koi8, но это в
данный момент не актуально), он перед записью на диск пытается
перекодировать из якобы utf8 в latin1. В результате при вставке в базе
данные необратимо портятся, а при считывании вместо русского лезет
испорченный юникод.

Пофиксить эту проблему можно несколькими способами:

1)  Отконвертировать базы в utf8 (сделать dump, отконвертировать его через
    iconv, изменить свойство CHARSET у всех CREATE TABLE, импортировать dump).
    ..... Ну, и перевести всю систему с koi8 на utf8. :) Желающие есть?

2)  При каждом коннекте с базой (т.е. при запуске mysql, pcalc и во всех
    perl-скриптах после DBI->connect()) выполнять sql-запрос
        set CHARACTER SET latin1;
    или
        set NAMES latin1;
    (я не разбирался пока чем они отличаются, работают оба вроде).
    Желающие есть? Как, опять нет? :)

3)  Заменить в /etc/mysql/my.cnf строки:
        default-character-set=utf8
    на
        default-character-set=latin1
    Желающих, не сомневаюсь, много. :) Но проблема в том, что это
    помогает не до конца. Это помогает только в тех программах, которые
    этот my.cnf считывают. А это исключительно mysql-клиент, в данный
    момент. Ни PHP, ни Perl этого не делают. Что касается PHP, то вроде
    бы только что (вчера, вроде) был выпущен исправленный ebuild, который
    фиксит эту проблему у PHP. А с Perl всё немного сложнее. Дело в том,
    что вообще-то DBD::mysql умеет считывать my.cnf, но для этого ему
    нужно при DBI->connect() передать специальную опцию - по умолчанию он
    этого не делает:
        $dbh = DBI->connect(
            "dbi:mysql:DATABASE;mysql_read_default_file=/etc/mysql/my.cnf",
            $user, $pass, ...);
    Это, безусловно, более универсально и правильно, чем прописывать во
    все perl-скрипты $dbh->do("set NAMES latin1"); но всё-равно менять все
    perl-скрипты облом.

4)  Добавить в /etc/mysql/my.cnf в секцию [mysqld] строку:
        init-connect='SET NAMES latin1'
    Насколько я понимаю, это приведёт к том, что после коннекта каждого
    клиента сервер будет для него автоматически выполнять этот запрос.
    Поскольку это будет делать сервер, то клиентам самим обрабатывать
    my.cnf нужды нет. Я, в данный момент, сделал именно так. Это самый
    ленивый способ, но какие у него могут быть негативные последствия
    пока не понятно... может это будет как-то конфликтовать с
    исправленным ebuild-ом PHP... или мешать работать действительно
    юникодным приложениям.

По большому счёту, самым правильным в данный момент является не цепляться
за этот latin1, а перейти на использование новых возможностей MySQL по
работе с charset-ами:
- отконвертировать все таблицы в корректные кодировки: koi8 и utf8
  (и задать их в свойствах этих таблиц, ессно)
- сделать во всех скриптах поддержку /etc/mysql/my.cnf (чтобы их можно
  было при необходимости все настраивать через этот файл)
- при коннекте к базе в скриптах указывать кодировку, в которой эти
  скрипты хотят работать (если их не устраивает дефалтовая utf8)