avl@l14.ru пишет:
> Alexander Bokovoy пишет:
> 
>> Greetings!
>>
>> Как обнаружилось нашим QA, вероятность присутствия пакета
>> glibc-gconv-modules в системе зависит только от желающих этот функционал
>> пакетов, коих оказалось очень мало. На сегодня в Сизифе
>> glibc-gconv-modules хотят только два пакета: iconv и glibc. Первый --
>> утилита командной строки, необязанная стоять в системе. Второй --
>> пакет-обертка над базовым функционалом Glibc, опять же, требуемый только
>> glibc-devel.
>>
>> Чем это плохо? Дело в том, что пакет glibc-gconv-modules предоставляет
>> динамические модули для iconv(3) в glibc. Отсутствие этого пакета ведет к
>> невозможности эксплуатации системного iconv() (наличие установленных
>> переменных окружения, переопределяющих директорию для поиска этих
>> динамических модулей, пренебрежимо мало) во всех приложениях, его
>> использующих. А это, например, все пакеты Gnome, Samba3, Netatalk, KDE.
>> Список можно продолжать.
>>
>> Думаю, что в ALT Packaging Policy следует добавить следующее правило:
>> -------------------------------------------------------------------------
>> Если упаковываемое приложение непосредственно вызывает системную функцию
>> iconv(3), то пакет обязан требовать присутствие пакета
>> glibc-gconv-modules: либо через Requires: glibc-gconv-modules, либо через
>> PreReq: glibc-gconv-modules, в случае, если предполагается запуск
>> приложения во время выполнения скриптов установки (%prein/%postin).
>>
>> В случае, если iconv(3) вызывается опосредованно, через некоторую
>> библиотеку (например, libglib2), то достаточно такую зависимость
>> установить только в используемой библиотеке.
>>
>> Помните, что упаковщик должен следовать "золотому правилу": минимум
>> предположений о среде, в которой будет использоваться пакет, максимум
>> фактов зависимостей задокументированных в самом пакете. Существует более
>> одного способа получить рабочую систему и единственное требование к 
>> ней со
>> стороны упаковщика должно быть удовлетворение всех описанных в пакете
>> зависимостей.
>> -------------------------------------------------------------------------
>>
>>  
>>
> Это, конечно, замечательно, что iconv можно теперь не ставить, нодолжна 
> же быть какая то база, при которой система считается фунциклирующей.
> По моему, нерабочий iconv(3), это нонсенс.  Пакеты, которые требуются 
> для его работы, должны требоваться basesystem или даже glibc, а не 
> каждому приложению.

Да, о том и речь.
Вообще я с этим столкнулся уже достаточно давно, но ldv@ меня убедил, 
что в принципе может быть система, в которой gconv-modules могут 
отсутствовать. Например - BTE.

Rgds,
Rider