[devel] W: build policy enhancement for packages using iconv()

[devel] W: build policy enhancement for packages using iconv()

[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), то достаточно такую зависимость
установить только в используемой библиотеке.

Помните, что упаковщик должен следовать "золотому правилу": минимум
предположений о среде, в которой будет использоваться пакет, максимум
фактов зависимостей задокументированных в самом пакете. Существует более
одного способа получить рабочую систему и единственное требование к ней со
стороны упаковщика должно быть удовлетворение всех описанных в пакете
зависимостей.
-------------------------------------------------------------------------

-- 
/ Alexander Bokovoy
---
Here comes the orator, with his flood of words and his drop of reason.

Re: [devel] W: build policy enhancement for packages using iconv()

[avl]

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, а не 
каждому приложению.

Re: [devel] W: build policy enhancement for packages using iconv()

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 2648 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 12:50:24PM +0400, Anton Farygin wrote:
> >Это, конечно, замечательно, что iconv можно теперь не ставить, нодолжна 
> >же быть какая то база, при которой система считается фунциклирующей.
> >По моему, нерабочий iconv(3), это нонсенс.  Пакеты, которые требуются 
> >для его работы, должны требоваться basesystem или даже glibc, а не 
> >каждому приложению.
> 
> Да, о том и речь.
> Вообще я с этим столкнулся уже достаточно давно, но ldv@ меня убедил, 
> что в принципе может быть система, в которой gconv-modules могут 
> отсутствовать. Например - BTE.
Это ошибочное мнение. glibc-devel в BTE присутствует всегда, rpm-build 
его хочет, а он через себя тянет glibc и следом glibc-gconv-modules. Так
что тезис о "системе, в которой gconv-modules могут отсутствовать" в виде BTE 
не подходит. Более того, в пакетах, использующих iconv(3) часто присутствует
проверка на работоспособность iconv(). И тут glibc-gconv-modules нужен.

Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в базовой
системе является ненужной переоптимизацией.
-- 
/ Alexander Bokovoy
---
Nothing succeeds like excess.
		-- Oscar Wilde

Re: [devel] W: build policy enhancement for packages using iconv()

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]

Alexander Bokovoy пишет:
> On Thu, Jul 10, 2003 at 12:50:24PM +0400, Anton Farygin wrote:
> 
>>>Это, конечно, замечательно, что iconv можно теперь не ставить, нодолжна 
>>>же быть какая то база, при которой система считается фунциклирующей.
>>>По моему, нерабочий iconv(3), это нонсенс.  Пакеты, которые требуются 
>>>для его работы, должны требоваться basesystem или даже glibc, а не 
>>>каждому приложению.
>>
>>Да, о том и речь.
>>Вообще я с этим столкнулся уже достаточно давно, но ldv@ меня убедил, 
>>что в принципе может быть система, в которой gconv-modules могут 
>>отсутствовать. Например - BTE.
> 
> Это ошибочное мнение. glibc-devel в BTE присутствует всегда, rpm-build 
> его хочет, а он через себя тянет glibc и следом glibc-gconv-modules. Так
> что тезис о "системе, в которой gconv-modules могут отсутствовать" в виде BTE 
> не подходит. Более того, в пакетах, использующих iconv(3) часто присутствует
> проверка на работоспособность iconv(). И тут glibc-gconv-modules нужен.
> 
> Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в базовой
> системе является ненужной переоптимизацией.

Я не возражаю - мне только проще будет ;-)

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

[devel] Re: W: build policy enhancement for packages using iconv()

[Michael Shigorin]

On Thu, Jul 10, 2003 at 01:00:18PM +0300, Alexander Bokovoy wrote:
> Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в
> базовой системе является ненужной переоптимизацией.

Т.е. в идеале было бы неплохо иметь возможность убрать, но только
если Знаешь, Что Делаешь, а в оставшихся 99% -- наличие
гарантировано?

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 04:20:02PM +0300, Michael Shigorin wrote:
> On Thu, Jul 10, 2003 at 01:00:18PM +0300, Alexander Bokovoy wrote:
> > Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в
> > базовой системе является ненужной переоптимизацией.
> 
> Т.е. в идеале было бы неплохо иметь возможность убрать, но только
> если Знаешь, Что Делаешь, а в оставшихся 99% -- наличие
> гарантировано?
Да. Большаков, конечно, придумал вариант в виде сервера с ftp, apache
(1.3), Tcl. То есть, где гарантировано iconv не используется. Только кому
нужен голый Apache? :) А всякие mod_perl, mod_php, tomkat, etc.. про iconv
знают.
-- 
/ Alexander Bokovoy
---
He keeps differentiating, flying off on a tangent.

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

Alexander Bokovoy пишет:
> On Thu, Jul 10, 2003 at 04:20:02PM +0300, Michael Shigorin wrote:
> 
>>On Thu, Jul 10, 2003 at 01:00:18PM +0300, Alexander Bokovoy wrote:
>>
>>>Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в
>>>базовой системе является ненужной переоптимизацией.
>>
>>Т.е. в идеале было бы неплохо иметь возможность убрать, но только
>>если Знаешь, Что Делаешь, а в оставшихся 99% -- наличие
>>гарантировано?
> 
> Да. Большаков, конечно, придумал вариант в виде сервера с ftp, apache
> (1.3), Tcl. То есть, где гарантировано iconv не используется. Только кому
> нужен голый Apache? :) А всякие mod_perl, mod_php, tomkat, etc.. про iconv
> знают.

Нужен голый FTP сервер. Часто. Голый apache - тоже используется во 
многих местах как http_proxy

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 06:07:46PM +0400, Anton Farygin wrote:
> Alexander Bokovoy пишет:
> >On Thu, Jul 10, 2003 at 04:20:02PM +0300, Michael Shigorin wrote:
> >
> >>On Thu, Jul 10, 2003 at 01:00:18PM +0300, Alexander Bokovoy wrote:
> >>
> >>>Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в
> >>>базовой системе является ненужной переоптимизацией.
> >>
> >>Т.е. в идеале было бы неплохо иметь возможность убрать, но только
> >>если Знаешь, Что Делаешь, а в оставшихся 99% -- наличие
> >>гарантировано?
> >
> >Да. Большаков, конечно, придумал вариант в виде сервера с ftp, apache
> >(1.3), Tcl. То есть, где гарантировано iconv не используется. Только кому
> >нужен голый Apache? :) А всякие mod_perl, mod_php, tomkat, etc.. про iconv
> >знают.
> 
> Нужен голый FTP сервер. Часто. Голый apache - тоже используется во 
> многих местах как http_proxy
4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
объеме. Для embedded люди скорее всего basesystem по-другому формировать
будут -- это так, для предупреждения соответствующего контраргумента.

-- 
/ Alexander Bokovoy
---
Go to a movie tonight.  Darkness becomes you.

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Alexander Bokovoy пишет:
> On Thu, Jul 10, 2003 at 06:07:46PM +0400, Anton Farygin wrote:
> 
>>Alexander Bokovoy пишет:
>>
>>>On Thu, Jul 10, 2003 at 04:20:02PM +0300, Michael Shigorin wrote:
>>>
>>>
>>>>On Thu, Jul 10, 2003 at 01:00:18PM +0300, Alexander Bokovoy wrote:
>>>>
>>>>
>>>>>Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в
>>>>>базовой системе является ненужной переоптимизацией.
>>>>
>>>>Т.е. в идеале было бы неплохо иметь возможность убрать, но только
>>>>если Знаешь, Что Делаешь, а в оставшихся 99% -- наличие
>>>>гарантировано?
>>>
>>>Да. Большаков, конечно, придумал вариант в виде сервера с ftp, apache
>>>(1.3), Tcl. То есть, где гарантировано iconv не используется. Только кому
>>>нужен голый Apache? :) А всякие mod_perl, mod_php, tomkat, etc.. про iconv
>>>знают.
>>
>>Нужен голый FTP сервер. Часто. Голый apache - тоже используется во 
>>многих местах как http_proxy
> 
> 4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
> объеме. Для embedded люди скорее всего basesystem по-другому формировать
> будут -- это так, для предупреждения соответствующего контраргумента.
> 

Да, для embedded - безусловно rpm2cpio ;-)

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 06:53:04PM +0400, Anton Farygin wrote:
> >>>Да. Большаков, конечно, придумал вариант в виде сервера с ftp, apache
> >>>(1.3), Tcl. То есть, где гарантировано iconv не используется. Только кому
> >>>нужен голый Apache? :) А всякие mod_perl, mod_php, tomkat, etc.. про 
> >>>iconv
> >>>знают.
> >>
> >>Нужен голый FTP сервер. Часто. Голый apache - тоже используется во 
> >>многих местах как http_proxy
> >
> >4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
> >объеме. Для embedded люди скорее всего basesystem по-другому формировать
> >будут -- это так, для предупреждения соответствующего контраргумента.
> >
> Да, для embedded - безусловно rpm2cpio ;-)
Ну зачем же так экстремально. :)
Можно проще -- rm -rf /var/lib/rpm


-- 
/ Alexander Bokovoy
---
A fail-safe circuit will destroy others.
		-- Klipstein

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Alexander Bokovoy пишет:
> On Thu, Jul 10, 2003 at 06:53:04PM +0400, Anton Farygin wrote:
> 
>>>>>Да. Большаков, конечно, придумал вариант в виде сервера с ftp, apache
>>>>>(1.3), Tcl. То есть, где гарантировано iconv не используется. Только кому
>>>>>нужен голый Apache? :) А всякие mod_perl, mod_php, tomkat, etc.. про 
>>>>>iconv
>>>>>знают.
>>>>
>>>>Нужен голый FTP сервер. Часто. Голый apache - тоже используется во 
>>>>многих местах как http_proxy
>>>
>>>4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
>>>объеме. Для embedded люди скорее всего basesystem по-другому формировать
>>>будут -- это так, для предупреждения соответствующего контраргумента.
>>>
>>
>>Да, для embedded - безусловно rpm2cpio ;-)
> 
> Ну зачем же так экстремально. :)
> Можно проще -- rm -rf /var/lib/rpm

Зачем ?

В Embedded системе не нужно огромное количество различных файлов... 
собственно если рассматривать программу установки как некую embedded 
систему, то в ней так и происходит - rpm2cpio то что нужно из пакетов, 
далее ldd на это и rpm2cpio то что получилось.. далее ldd на то, что 
получилось и далее до упора... не все конечно так просто, но примерно так.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 07:32:21PM +0400, Anton Farygin wrote:
> >>
> >>Да, для embedded - безусловно rpm2cpio ;-)
> >
> >Ну зачем же так экстремально. :)
> >Можно проще -- rm -rf /var/lib/rpm
> 
> Зачем ?
> 
> В Embedded системе не нужно огромное количество различных файлов... 
> собственно если рассматривать программу установки как некую embedded 
> систему, то в ней так и происходит - rpm2cpio то что нужно из пакетов, 
> далее ldd на это и rpm2cpio то что получилось.. далее ldd на то, что 
> получилось и далее до упора... не все конечно так просто, но примерно так.
Непродуктивно. Поскольку embedded система изготавливается в
hosted-системе, то используем в ней rpm и apt, и сводим задачу к н.у.

То, что после установки можно запустить процесс чистки ненужных компонент
-- вполне естественное явление. 

Может быть ты монимаешь под embedded что-то отличное от? Я имею в виду
системы, чья пакетная база неизменяема в процессе использования, а
обновление производится переписыванием начисто пакетной базы с корректным
сохранением имеющейся конфигурации.

То, что подавляющее большинство изготовителей embedded не пользуются
пакетными менеджерами, оставим на совести этих изготовителей. Опыт
показывает, что и среди изготовителей более крупноформатных изданий
(дистрибутивов общего пользования, например) в этом отношении еще разброд
и шатание.
-- 
/ Alexander Bokovoy
---
Love IS what it's cracked up to be.

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Sergey Bolshakov]

>>>>> "Alexander" == Alexander Bokovoy <a.bokovoy@sam-solutions.net> writes:
[skipped]
 > 4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
 > объеме. Для embedded люди скорее всего basesystem по-другому формировать
 > будут -- это так, для предупреждения соответствующего контраргумента.

Цена вопроса == цене информации о том, что некий пакет хочет
эти 4Mb. Таки хочет или таки нет ? Предложение включить эти 4Mb 
в basesystem -- это предложение замазать вопрос.

-- 

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Anton Farygin]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

Sergey Bolshakov пишет:
>>>>>>"Alexander" == Alexander Bokovoy <a.bokovoy@sam-solutions.net> writes:
> 
> [skipped]
>  > 4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
>  > объеме. Для embedded люди скорее всего basesystem по-другому формировать
>  > будут -- это так, для предупреждения соответствующего контраргумента.
> 
> Цена вопроса == цене информации о том, что некий пакет хочет
> эти 4Mb. Таки хочет или таки нет ? Предложение включить эти 4Mb 
> в basesystem -- это предложение замазать вопрос.
> 

Хочет, когда нужна определенная функциональность и не хочет - когда не 
нужна.

Rgds,
Rider

[-- Attachment #2: Type: application/pgp-signature, Size: 252 bytes --]

Re: [devel] Re: W: build policy enhancement for packages using iconv()

[Алексей Любимов]

Sergey Bolshakov пишет:

>>>>>>"Alexander" == Alexander Bokovoy <a.bokovoy@sam-solutions.net> writes:
>>>>>>            
>>>>>>
>[skipped]
> > 4Мб данных из glibc-gconv-modules там помешают? Цена вопроса именно в этом
> > объеме. Для embedded люди скорее всего basesystem по-другому формировать
> > будут -- это так, для предупреждения соответствующего контраргумента.
>
>Цена вопроса == цене информации о том, что некий пакет хочет
>эти 4Mb. Таки хочет или таки нет ? Предложение включить эти 4Mb 
>в basesystem -- это предложение замазать вопрос.
>  
>
Русская система без iconv , это чистый embeded.
если ставить ВСЕ зависимости, то мы опухнем под грузом ошибок в этих 
самых зависимостях.
Только что прошла мозилла с аналогичной "оптимизацией" и ничему не научила?

[devel] Re: W: build policy enhancement for packages using iconv()

[Michael Shigorin]

On Thu, Jul 10, 2003 at 05:54:04PM +0300, Alexander Bokovoy wrote:
> 4Мб данных из glibc-gconv-modules там помешают? Цена вопроса
> именно в этом объеме. Для embedded люди скорее всего basesystem
> по-другому формировать будут -- это так, для предупреждения
> соответствующего контраргумента.

Тогда, наверное, имеет смысл разнести basesystems.  Для
J/C/small_ftp они вроде как действительно разные? :)

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [devel] W: build policy enhancement for packages using iconv()

[avl]

>
>
>Как обнаружилось нашим QA, вероятность присутствия пакета
>glibc-gconv-modules в системе зависит только от желающих этот функционал
>пакетов, коих оказалось очень мало.
>
>
>Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в базовой
>системе является ненужной переоптимизацией.
>  
>
таки к чему пришел наш QA?
будет добавлена зависимость в basesystem?

Re: [devel] W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 05:33:45PM +0400, avl@l14.ru wrote:
> >
> >
> >Как обнаружилось нашим QA, вероятность присутствия пакета
> >glibc-gconv-modules в системе зависит только от желающих этот функционал
> >пакетов, коих оказалось очень мало.
> >
> >
> >Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в базовой
> >системе является ненужной переоптимизацией.
> таки к чему пришел наш QA?
Наш = Optifacio. QA в ALT Linux молчит. Но не это важно, главное,
чтобы maintainer basesystem пришел к окончательным выводам. :) А он пока в
отпуске.

> будет добавлена зависимость в basesystem?
Крайне рекомендовано.

-- 
/ Alexander Bokovoy
---
Most legends have their basis in facts.
		-- Kirk, "And The Children Shall Lead", stardate 5029.5

Re: [devel] W: build policy enhancement for packages using iconv()

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 828 bytes --]

On Thu, Jul 10, 2003 at 05:13:13PM +0300, Alexander Bokovoy wrote:
> On Thu, Jul 10, 2003 at 05:33:45PM +0400, avl@l14.ru wrote:
> > >
> > >Как обнаружилось нашим QA, вероятность присутствия пакета
> > >glibc-gconv-modules в системе зависит только от желающих этот функционал
> > >пакетов, коих оказалось очень мало.
> > >
> > >Вообщем, с моей точки зрения отсутствие glibc-gconv-modules в базовой
> > >системе является ненужной переоптимизацией.
> > таки к чему пришел наш QA?
> Наш = Optifacio. QA в ALT Linux молчит. Но не это важно, главное,
> чтобы maintainer basesystem пришел к окончательным выводам. :) А он пока в
> отпуске.
> 
> > будет добавлена зависимость в basesystem?
> Крайне рекомендовано.

Что такое basesystem, сколько каких *system должно быть - эта как раз в
тематике LF, предлагаю там и обсудить.


--
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [devel] W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Sun, Jul 20, 2003 at 02:50:13PM +0400, Dmitry V. Levin wrote:
> > > будет добавлена зависимость в basesystem?
> > Крайне рекомендовано.
> 
> Что такое basesystem, сколько каких *system должно быть - эта как раз в
> тематике LF, предлагаю там и обсудить.
Согласен.

-- 
/ Alexander Bokovoy
---
If love is the answer, could you rephrase the question?
		-- Lily Tomlin

Re: [devel] W: build policy enhancement for packages using iconv()

[Alexander Bokovoy]

On Thu, Jul 10, 2003 at 10:33:29AM +0400, avl@l14.ru wrote:
> же быть какая то база, при которой система считается фунциклирующей.
> По моему, нерабочий iconv(3), это нонсенс.  Пакеты, которые требуются 
> для его работы, должны требоваться basesystem или даже glibc, а не 
> каждому приложению.
Согласен. Пакет glibc -- это обертка. Нужно, чтобы требовались
glibc-gconv-modules на более фундаментальном уровне. Или пусть basesystem
хочет glibc.
-- 
/ Alexander Bokovoy
---
love, n.:
	When you don't want someone too close--because you're very sensitive
	to pleasure.