Smart Package Manager 1.0

>> только в smartpm лучше depsolver

> это можно сделать лучше чем в апт?

apt'овский - отнюдь не фонтан (по крайней мере, в apt для RPM). На странице SmartPM приводятся примеры неоптимального вычисления зависимотей apt и yum. А "best depsolver" сказал о SmartPM сам Jeff Johnson :)

Народ, зачем нужен такой комбайн? Это же не юникс-вей. Или это строится основа для дистрибутива LOR-Linux, чтоб красноглазые из-за менеджера пакетов не дрались?

> На странице SmartPM приводятся примеры неоптимального вычисления зависимотей apt и yum.

Тогда стоит взглянуть. Хотя меня больше deb интересуют.

> А "best depsolver" сказал о SmartPM сам Jeff Johnson

Jeff Johnson = ?

гугль выбрасывает инфу о слишком разных JJ.

> народ, зачем нужен такой комбайн? Это же не юникс-вей.

Если выяснится, что это фигня лучше чем apt, я возможно переползу на нее.

> чтоб красноглазые из-за менеджера пакетов не дрались?

Вообще-то именно так и должно быть. Хотя бы на 2-м уровне (поверх deb, rpm, etc...) единый менеджер пакетов.

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

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

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

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

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

> Jeff Johnson = ?

Человек, который дольше всех поддерживал RPM (RedHat 6,x - RHEL4, кажется).

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

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

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

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

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

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

Оно чем-то лучше PackageKit?

>генту -- ненужен

Gentoo нужен! =) Более гибкой системы пакетов чем в генту я не видел. Пусть даже все ставится из исходников.

з.ы. А в бинарях вечный гимор с зависимостями...

> А в бинарях вечный гимор с зависимостями...

Афигеть, в 2008 году еще остались живые ниасиляторы apt-get

Попробовал это поделие. 2 момента: не умеет pdiff'ы при апдейте (вообще качает все заново), ужасно тормозит по сравнению с apt-get/apt-cache. Уже достаточно что бы провести apt-get purge smartpm.

выяснилось - что не лучше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ммм... что решение на поверхности - это понятно. Но, видимо, дебиан со мной согласен, что smartpm - ненужен =). apt, aptitude, synaptic - этого вполне достаточно.

когда-то предпочитал смарт всем другим пакетным менегарам, сейчас действительно Yast рулит

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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