Я пытаюсь использовать debconf для предварительной установки значений для locales пакет в Debian squeeze, чтобы я мог перенастроить его в неинтерактивном режиме, например, для генерации всех локалей. Я извлекаю правильный выбор из рабочей системы, используя debconf-get-selections, а затем скормить им debconf-set-selections по новой системе.
Он работает для других пакетов, например. sun-java6-bin, не совсем для locales. Я могу установить значения с помощью debconf-set-selections, но если я перенастрою locales с участием dpkg-reconfigure (или переустановите его, например, apt-get install --reinstall locales, если на то пошло), значения сбрасываются, а новые языковые стандарты не создаются.
Симптомы точно такие же, как у ошибка debian # 592216, но эта ошибка официально исправлена в версии 2.9-13 пакета. Squeeze имеет 2.11.3-4, так что либо ошибка все еще существует, либо я что-то делаю не так.
Кто-нибудь испытал то же самое?
заранее спасибо
- М
Мне удалось создать политику cfengine3, похожую на манифест @cosimo, и, похоже, она работает. Меня это устраивает, но я по-прежнему считаю, что ошибка № 592216 еще не решена, поэтому я могу передать еще одну в Debian.
Моя реализация cfengine использует тот факт, что /etc/locale.gen кажется, содержит все возможные локали, но закомментированы.
Вместо того, чтобы переписывать файл с нуля и, возможно, вносить ошибки, я прошу cfengine раскомментировать локали, которые я хочу создать. Если языковой стандарт отсутствует, потому что он не поддерживается или я написал его неправильно, ничего не происходит. Этот подход также упрощает ситуацию, поскольку нет необходимости писать обе локаль и кодировка: вы можете просто написать языковой стандарт и позволить cfengine раскомментировать все связанные кодировки для этого языкового стандарта.
'достаточно:
body common control
{
inputs => { "cfengine_stdlib.cf" } ;
bundlesequence => {"test"} ;
}
bundle agent test
{
vars:
"locales"
slist => { "da_DK.UTF-8", "de_DE.UTF-8", "en_US.UTF-8",
"es_ES.UTF-8", "fr_FR.UTF-8", "it_IT.UTF-8",
"nl_NL.UTF-8", "ru_RU.UTF-8", "sv_SE.UTF-8",
"tr_TR.UTF-8", "id_ID.UTF-8", "nb_NO.UTF-8",
"pl_PL.UTF-8", "vi_VN.TCVN" },
comment => "locales to generate" ;
files:
"/etc/locale.gen"
edit_line => enable_locales(@(test.locales)),
classes => if_repaired("regenerate_locales"),
comment => "Enable locales, trigger locale-gen if needed" ;
commands:
regenerate_locales::
"/usr/sbin/locale-gen"
comment => "Regenerate locales when needed" ;
reports:
regenerate_locales::
"Locales regenerated" ;
}
bundle edit_line enable_locales(locales)
{
replace_patterns:
"^#\s+($(locales).*)$"
replace_with => uncomment ;
}
Да, у меня возникла та же проблема, и после некоторой борьбы с ней я нашел обходной путь, который использует /etc/locale.gen.
Я опубликовал марионеточный модуль для настройки локалей, которые мы обычно используем на наших серверах, то есть только en_US.UTF-8:
https://github.com/cosimo/puppet-modules/blob/master/locales/manifests/init.pp
Вот он, встроенный:
class locales {
package { "locales":
ensure => "latest",
}
file { "/etc/locale.gen":
source => [
"puppet:///locales/locale.gen.$fqdn",
"puppet:///locales/locale.gen"
],
owner => "root",
group => "root",
mode => 644,
require => Package["locales"],
}
exec { "/usr/sbin/locale-gen":
subscribe => File["/etc/locale.gen"],
refreshonly => true,
require => [ Package["locales"], File["/etc/locale.gen"] ]
}
}
Даже если вы не используете марионетку ;-), вы легко поймете, что происходит. Вы просто создаете /etc/locale.gen файл со списком локалей, которые вы хотите создать, а затем запустите /usr/sbin/locale-gen.
Вот файл списка, который я использую как /etc/locale.gen:
# 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/local/share/i18n/SUPPORTED. If you change
# this file, you need to rerun locale-gen.
en_US.UTF-8 UTF-8