Re: [devel] Минимальный VE огромен -- много мусора

[Led <ledest@gmail.com>]

On Tuesday 29 April 2014 16:40:44 Денис Смирнов wrote:
> On Tue, Apr 29, 2014 at 02:39:11AM +0300, Led wrote:
> >> Это параллельная задача. Ценности отпиливания mtrace в отдельный пакет,
> >> для избавления от перловки это не отменяет.
> >
> > Это не задача. Это то, что реально проверено.
>
> И ты предлагаешь это изменение ради какой-то задачи, которая похоже
> отличается от моей, и потому я прошу её озвучить -- чтобы все понимали что
> и зачем делаем.

Я всего лишь привёл пример подобного опыта.

>
> Сейчас ситуация такая -- пакет с именем 'glibc' имеет непрямую зависимость
> на 'perl-base', что с любой точки зрения является некорректным как чисто
> технически (кольцевая зависимость),

И где там "кольцевая зависимость"?

> с точки зрения безопасности и качества 
> (любая лишняя зависимость на объемное приложение -- зло).

Не спорю.

>
> Предложенное тобой изменение оставит mtrace в пакете glibc-utils, что хоть
> и решит проблему частично, но оставит неочевидную зависимость.

Какую?

>
> Цель предложенного мной изменения -- минимизация зависимостей и отделение
> имеющих существенные зависимости приложений в отдельные подпакеты, ради
> возможности проще создавать компактные минималистичные VE, что является
> существенным в связи с тенденцией использовать подход 'одно приложение --
> одно VE'
>
> Единственным препятствием для отделение mtrace в отдельный подпакет
> является тот факт, что отдельный пакет для маленького скриптика это
> overhead.
>
> Я уверен, что возможность легче создавать минималистичные VE, вместе с
> отсутствием неочевидной зависимости от пакетов с именем 'glibc*' от
> перловки стоит того, чтобы потратить на это несколько килобайт метаданных
> в репоизтории.
>
> Поэтому вне зависимости от решения по переносу бинарников между glibc и
> glibc-utils, отпилить конкретно mtrace в отдельный пакет с именем, не
> содержащим префикс 'glibc' считаю необходимым, или как минимум лучшим чем
> любое другое известное мне решение.

В glibc-utils находятся как утилиты, которые ИМХО должны быть в любой (даже 
самой минимальной) системе (getconf, getent, ldd), так и утилиты, 
которые "возможно, когда-нибудь, кому-нибудь, в каких-то случаях могут 
понадобиться" (среди них и mtrace). Зачем вводить новые субпакеты, когда 
можно первые внести в glibc, туда же положить сиротливый iconv и утилиты из 
glibc-timezones, и оторвать в glibc зависимости на glibc-tools, iconv, 
glibc-locales, glibc-timezones.

-- 
Led