Российское сообщество openSUSE входит в тройку крупнейших

> Но будем надеяться, что что-то изменилось. Я тогда так и не нашел способа посмотреть список файлов, включенных в пакет (dpkg -L) или определить, какому пакету принадлежит тот или иной файл (apt-file search).

Долго не мог запомнить dpkg -L и dpkg -S, да и сейчас путую, а 'rpm -ql пакет' и 'rpm -qf /.../файл' всегда понятно и запоминаемое.

>Заключение

Диагноз неутешительный

> и его mono,которое он повсюду хочет впихнуть

Столько желчи, учитывая, что Вы явно не в теме...

> ругаться, что не может _что-то_ обновить

Делаем вывод ;)

Ты предсказуем.

Так по существу есть что сказать? А лучше пропади отсюда.

А то узнавать твой словарный запас нецензурщины абсолютно не интересно.

Что там насчет моно, напиханного по твоему утверждению куда только можно? Сусе есть, моно нет. Получается ты вложился в усиление парникового эффекта на планете?

>> определить, какому пакету принадлежит тот или иной файл (apt-file search).

zypper search browser

Нет, это не то, а правильно будет rpm -ql, кажется.

> Долго не мог запомнить dpkg -L и dpkg -S, да и сейчас путую, а 'rpm -ql пакет' и 'rpm -qf /.../файл' всегда понятно и запоминаемое.

И то, и другое одинаково запоминается. В общем, понятно, что с точки зрения package managers zypper/rpm не проигрывает apt/deb. Ну, значит, остается только недостаточно большой дефолтный репозиторий.

> И то, и другое одинаково запоминается. В общем, понятно, что с точки зрения package managers zypper/rpm не проигрывает apt/deb.

Дело не в тулзах, дело в самих пакетных системах. Я убедился, что RPM намного надежнее, чем DEB и риск поломать систему гораздо меньше. К Сусе можно спокойно подключать любые репы, потому что она обновляет пакеты только от того же поставщика, от которого они установлены, в отличие гот убунты. Проблемы с несовместимостью тоже гораздо меньше, потому что deb-система смотрит зависимости по названиям пакетов, а rpm - по входящим в пакет библиотекам. Суся никогда не будет обновлять пакет на новую версию, если в новой версии отсутствует библиотека, которая используется другим пакетом. А убунте - все равно, лишь бы название пакета совпадало и номер версии был больше.

Ну, значит, остается только недостаточно большой дефолтный репозиторий.

Просто в Сусе не тащат всякий мусор в основной репозиторий, там только проверенные проги с фирменным новелловским оформлением. Впрочем, он все равно на втором месте после дебиановского (и в разы больше федоровского), но при этом еще есть репозиторий сообщества Пакман, аналогов которому нету в дебиане, и крупные репы в OBS (например, OpenSUSE Education, Games и т.д.) плюс можно устанавливать пакеты от других дистров (федора, мандрива, альт).

Кстати, где для опенсуси взять мультипоточный mplayer?

Это пакетная зависимость по прямому пути до какого-либо файла.

Например, мы можем прописать себе зависимость на /usr/sbin/sendmail и не париться на тему «перечислить зависимости на всевозможные почтовые серверы доступные в нашем дистрибутиве». Тем более, что rpm не поддерживает пакетные зависимости в стиле debian: «такой-то пакет ИЛИ другой».

Как-то так.

Уточню: ограниченно поддерживает. Пруф: https://bugzilla.novell.com/show_bug.cgi?id=535017

>Например, мы можем прописать себе зависимость на /usr/sbin/sendmail и не париться на тему «перечислить зависимости на всевозможные почтовые серверы доступные в нашем дистрибутиве».

а чем это лучше обычной зависимости от пакета sendmail?

Тем более, что rpm не поддерживает пакетные зависимости в стиле debian: «такой-то пакет ИЛИ другой».

в приведенном примере с sendmail не понятно, чем поможет эта фича: «такой-то пакет ИЛИ другой».

по идее /usr/sbin/sendmail может предоставлять не один только пакет sendmail

хм, зоопарк какой-то. а что делать если есть, скажем 2 пакета, оба в числе прочего предоставляют, скажем /usr/sbin/sendmail. при этом первый установлен, а я хочу установить и второй.

они должны конфликтовать между собой :) либо удаляй старый, либо не ставь новый

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

да хотя бы на примере того же сендмыла, есть ведь разные mta, а «стандарт» на отправку через sendmail один...

>>Например, мы можем прописать себе зависимость на /usr/sbin/sendmail и не париться на тему «перечислить зависимости на всевозможные почтовые серверы доступные в нашем дистрибутиве».

а чем это лучше обычной зависимости от пакета sendmail?

Тем, что mta нынче много разных, и не во всяком нынче дистрибутиве есть sendmail, но все mta имеют эмулятор сендмейла /usr/sbin/sendmail

Тем более, что rpm не поддерживает пакетные зависимости в стиле debian: «такой-то пакет ИЛИ другой».

в приведенном примере с sendmail не понятно, чем поможет эта фича: «такой-то пакет ИЛИ другой».

«/usr/sbin/sendmail» это уже как бы стандарт. Его поддерживают все mta. Фича помогла бы писать не файловую зависимость, а пакетную типа: sendmail | qmail | postfix

Мне такой вариант нравится больше, чем прямая файловая зависимость.

> Уточню: ограниченно поддерживает. Пруф: https://bugzilla.novell.com/show_bug.cgi?id=535017

Ну это просто баг, который в каких-то спец. условиях проявляется.