Smart Package Manager 1.0

>> Т.е потихоньку PM генту становится библиотекой, которую может использовать любой другой дистрибутив, приспособив для себя

>Вопрос только - зачем? У всех уже всё есть.

В бинарных дистрибутивах осуществляется управление только бинарными зависимостями, а зависимости при компиляции не управляются в том смысле, что они статичны, их невозможно изменять, хотя отсекание ненужных зависимостей очень полезно.

> В бинарных дистрибутивах осуществляется управление только бинарными зависимостями, а зависимости при компиляции не управляются в том смысле, что они статичны, их невозможно изменять

Возможно. Другое дело, что в бинарных дистрах это не особо нужно.

В Deb есть "мягкие" завсимисти, которые в отличие от "жёстких" можно не устанавливать мо желанию пользователя.

>> В бинарных дистрибутивах осуществляется управление только бинарными зависимостями, а зависимости при компиляции не управляются в том смысле, что они статичны, их невозможно изменять

>Возможно. Другое дело, что в бинарных дистрах это не особо нужно.

Чем меньше ненужных зависимостей будет в бинарнике, тем он лучше и надёжнее будет. Это же вполне очевидно. Как минимум в этом смысле комплиляция безальтернативна.

>В Deb есть "мягкие" завсимисти, которые в отличие от "жёстких" можно не устанавливать мо желанию пользователя.

В дебиане безусловно разбиение пакетов сделано более гибким образом, но этого всё равно мало, я как то приводил пример, php имеет не меньше 80 USE флагов, в дебиане нет такого разбиения. И эта картина характерна для всех пакетов.

> Чем меньше ненужных зависимостей будет в бинарнике

Еще раз - в бинарных дистрах возможно указание опций компиляции, и это может влиять на зависимости получаемых пакетов. Но, поскольку это не конструкторы caveat emptor типа Генты, то...

> тем он лучше и надёжнее будет. Это же вполне очевидно.

...даже про "надежнее, если меньше зависимостей" не очевидно. А если зависимости (== опции сборки) просто другие, то твоя фраза - просто 4.2

> Как минимум в этом смысле комплиляция безальтернативна.

Компиляция безальтернативна при выбрасывании возможностей, да. Этого вполне можно достичь в том же RPM, но перед разработчиками RH, SuSE и Mandriva просто не стоит такой задачи.

>> Чем меньше ненужных зависимостей будет в бинарнике

>Еще раз - в бинарных дистрах возможно указание опций компиляции, и это может влиять на зависимости получаемых пакетов.

Это больше возможности получить гимор, чем реальную пользу, так как делается не удобным образом, редактированием скрипта компиляции, и нет ни одного инструмента, который отслеживал бы изменившиеся зависимости.

>Но, поскольку это не конструкторы caveat emptor типа Генты, то...

Выход за границы ...

Я ведь ограничил определенными границами рассмотрение пользы от перекомпиляции, неправда ли ?

>> тем он лучше и надёжнее будет. Это же вполне очевидно.

>...даже про "надежнее, если меньше зависимостей" не очевидно.

:-) Ты просто шутишь

>А если зависимости (== опции сборки) просто другие, то твоя фраза - просто 4.2

Я этого не говорил

>> Еще раз - в бинарных дистрах возможно указание опций компиляции, и это может влиять на зависимости получаемых пакетов.

> Это больше возможности получить гимор, чем реальную пользу, так как делается не удобным образом, редактированием скрипта компиляции

По-моему, ты просто незнаком с механизмом --with в RPM.

> и нет ни одного инструмента, который отслеживал бы изменившиеся зависимости.

? apt, yum и сабж - не отслеживают зависимостей?

>>Но, поскольку это не конструкторы caveat emptor типа Генты, то...

> Выход за границы ...

Выход за границы чего? Коммерческие дистры типа RHEL дают какие-то гарантии, осуществляют поддержку за деньги. Для этого нужно иметь проверенный набор софта - т.е. протестированный на совместное функционирование. Протестировать соместную работу программ, собранных со всеми комбинациями опций просто невозможно. Поэтому легкость их изменения не так важна.

>>...даже про "надежнее, если меньше зависимостей" не очевидно.

>:-) Ты просто шутишь

Нет. Всё дело в тестировании - случай с "меньше зависимостей" вполне может быть просто непроверенным.

>> А если зависимости (== опции сборки) просто другие, то твоя фраза - просто 4.2

> Я этого не говорил

Тогда я не понял, что именно ты сказал.

>>> Еще раз - в бинарных дистрах возможно указание опций компиляции, и это может влиять на зависимости получаемых пакетов.

>> Это больше возможности получить гимор, чем реальную пользу, так как делается не удобным образом, редактированием скрипта компиляции

>По-моему, ты просто незнаком с механизмом --with в RPM.

команду написать можешь ?

>> и нет ни одного инструмента, который отслеживал бы изменившиеся зависимости.

>? apt, yum и сабж - не отслеживают зависимостей?

Вообще то для данного случая в дебиане есть apt-source и apt-build. Они просто предназначены для компиляции при уже выбранных разработчиками флагах. В документации дебиана специально предостерегают от компиляции с другими флагами. И изменившиеся зависимости они не обрабатывали, зависимые пакеты рекурсивно не обновляли.

>>>Но, поскольку это не конструкторы caveat emptor типа Генты, то...

>> Выход за границы ...

>Выход за границы чего? Коммерческие дистры типа RHEL дают какие-то гарантии, осуществляют поддержку за деньги. Для этого нужно иметь проверенный набор софта - т.е. протестированный на совместное функционирование. Протестировать соместную работу программ, собранных со всеми комбинациями опций просто невозможно. Поэтому легкость их изменения не так важна.

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

>>>...даже про "надежнее, если меньше зависимостей" не очевидно.

>>:-) Ты просто шутишь

>Нет. Всё дело в тестировании - случай с "меньше зависимостей" вполне может быть просто непроверенным.

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

>>> А если зависимости (== опции сборки) просто другие, то твоя фраза - просто 4.2

>> Я этого не говорил

>Тогда я не понял, что именно ты сказал.

Я говорил только об определенном случае, когда использование перекомпиляции оправданно. На серверах стабильность как правило важнее новизны софта и производительности, потому я ограничился рассмотрением только одного случая.

> Наличие большого количества флагов компилляции требует огромного количества тестирования, и потому отключение ненужных зависимостей может только увеличить надежность

Опять двадцать пять... Каждый, кто считает себя достаточно умным, выкинет по фиче, и в результате затраты на тестирование распылены.

> На серверах стабильность как правило важнее новизны софта и производительности

Это значит, что нужно придерживаться хорошо протестированных конфигураций, а выигрыши от выкидывания фич не важны?

>> Наличие большого количества флагов компилляции требует огромного количества тестирования, и потому отключение ненужных зависимостей может только увеличить надежность

>Опять двадцать пять... Каждый, кто считает себя достаточно умным, выкинет по фиче, и в результате затраты на тестирование распылены

Ну не совсем так, я бы сказал, что оба варианта надо применять совместно, нужно тестрировать по максимуму общую конфигурацию, и надо выкидывать всё, что не нужно.

Причем разговор от бинарных дистрибутивов у нас плавно свелся к платным серверным, что совсем не одно и то же. И иметь возможность управлять сборкой даже на бинарных дистрибутивах просто необходимо, т.к раз они предоставляют исходники, значит и PM должны предоставлять. Исходники тоже предполагают PM. Спорить на эту тему глупо, мы же не спорим, что нужны PM для управления бинарными зависимостями.