Проблема есть. В случае с rpm тебе сам rpm скажет в чем проблема, а в случае с deb ты потратишь кучу времени, разбираясь почему ничего не работает.

Если слинковано к симлинку, то и в rpm всё будет всё ok.

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

Еще раз повторю. Если бы ты собирал rpm-пакет, то благодаря автоматическим зависимостям твой пакет бы ставился и работал на ЛЮБОЙ системе, на которой есть все необходимые файлы. То есть, если в принципе бинарные файлы, входящие в пакет, могут работать в системе, проблем с зависимостями не будет. И ручная правка зависимостей не нужна.

лол. откуда такой вывод?

От выхлопа работы ldd. как тут сверху подсказывает тов. Reset.

Я не знаю, когда их там не было. Лет пять назад были и широко использовались.

В ведь в 2009-м году перед берлинской конференцией по packaging API они ещё только обсуждали, будут они их делать или нет, а у Nxx к этому времени они уже два года как работали и широко использовались.

Я понял — тебе подсунули Debian, а ты до сих пор думаешь, что это Suse ;))))

в случае с deb ты потратишь кучу времени, разбираясь почему ничего не работает.

Примеры можно? Про rpm ничего плохого не скажу, но rpm-ные дистры уже 4 года не использую, только deb-based, повезло наверное, но ни разу проблем с установкой/обновлением/удалением не было.

Так, на всякий случай: http://www.rpm.org/max-rpm/ch-rpm-depend.html

Вдруг кто найдёт в этой документации упоминание мягких зависимостей — сообщите.

Имя пакта по файлу определяется из метаинформации полученной из репозитория. Если в репозитории нет информации по искомому файлу то кирдык, что и происходит.

ЛОЛ. В ЛЮБОМ rpm-пкете всегда есть информация о ВСЕХ входящих в его состав библиотеках.

Неконсистентные зависимости могут быть только при ручном прописывании зависимостей.

Нет же. Такое бывает если набор репозиториев на сборочной машине не совпадает с моим (т.е. больше моего) то есть например с епелом или еще с чемнибудь типа репы с более новой или более старой версией дистра.

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

Проблема есть. В случае с rpm тебе сам rpm скажет в чем проблема, а в случае с deb ты потратишь кучу времени, разбираясь почему ничего не работает.

Это если столкнёшься, что оно не работает. Ну да, в этом смысле rpm лучше, но с другой стороны — я привёл пример, который в rpm приводит к тому, что пакет поставить можно только с костылём, а в deb он будет работать. Разные подходы — разные проблемы.

Вернёмся к топику?

Нет не будет. Потому что в рпм я увижу имя симлинка а не имя пакета где лежит соотв файл.

поставить можно только с костылём, а в deb он будет работать.

Почему он будет работать? В твоем случае он не работать будет, а ставиться без --force --nodeps, но работать также не будет.

Имя пакета по симлинку находится с помощью urpmf.

Однако ж имя нужного пакета это огромный плюс при поиске нехватающей зависимости.

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

А имя файла тоже ни о чем не говорит. Мало ли кто как собрал одну и ту же версию библиотеки?

Там проверяется не только имя файла, но и версия ABI, и архитектура, и другая информация, если она имеется. Это все прописывается автоматически.

Правильно. Из этой инфы и образуется метадата репозитория. Для быстрого поиска пакета по файлу.

Я говорил про ситуацию когда в репе лежит пакет в котором есть зависимость от файла для котрого в этой репе нет пакета.

Формат предоставляет для этого все возможности. Если мантейнер ими не воспользовался, ругать надо не формат, а мантейнера. В большинстве случаев стандартные debian'овские пакеты вполне нормально следят за совместимостью. Если нет, никто не мешает донастроить под себя. И в плане сборки своих пакетов тут вообще рай.

Может быть rpm крут и даже намного лучше deb. Я этого не знаю, потому что работал с rpm-based только как пользователь и очень давно(был сервер на RedHat 7.1, рутер на Fedora 6 и Mandracke 8.2 на десктопе когда-то). Но после плотного знакомства с deb, я пока себе не представляю, что может быть удобнее.

Почему он будет работать? В твоем случае он не работать будет, а ставиться без --force --nodeps, но работать также не будет.

А. Да.

Моё мнение о новости подчерпнуто из Опеннета. RHEL + CentOS в сумме гораздо популярнее Ubuntu. Сколько там процентов пользователей с коммерческой поддержкой в Убунте - вопрос.

Ubuntu + Debian = 48,4%
RHEL + CentOS = 41,1%

Пруф. Ибо это гон.

Я не знаю, как в других дистрибутивах, но в openSUSE Build Service репозиторий не публикуется, пока все сборочные задачи в нем не завершены. Это значит, что если версия какой-то библиотеки обновлены, автоматически будут пересобраны все зависящие от нее пакеты и опубликованы одновременно.

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

Ты еще Fedora и SuSE приплюсуй.

Пошел второй круг. Считай, что libwtf.so.1.0.0 это симлинк.

Из бекпортов только несколько пакетов. Остально или из testing(postgres, python2.7), или из sid(nginx), или самосборное(python3.0).

Разговор глухого со слепым. Не интересно :(

Интересно, как система автоматически определит, что мне нужна библиотека версии 2.0.x, где x—любое число? Допустим, разработчики меняют только производительность в рамках минорных изменений, да накладывают security пачти.

Тогда имя файла библиотеки не поменяется. so-name меняется только при изменении ABI. Если файлы совместимы, то и имя у них общее, даже если версия пакета с библиотекой (и тарбола) отличается. Это общее правило UNIX.

Обычно это делается так — симлинк от libastral.so.2.0. на libastral.so.2.0.5, как я писал уже выше.

У кого это «обычно» так делается? Если так сделаешь, то высока вероятность получить крах во время выполнения.

Что это провокационный бред делает на главной?

Что мешает подключить unstable-ветку deb-src, не подключая deb?

А не приходило в голову, что в unstable пакеты могут быть пакеты могут быть не совместимыми со stable или вообще отсутствовать те, которые есть в stable?

Апрель близится. Всё чаще и чаще появляются «новости» про бубунту. Традиция последних лет.

Сегодня в почтовый ящик пришло уведомление: посылка СР100267298UZ 2 кг. 890 г. Узбекистан.
Твоя работа?

Посмотрел вокруг, посмотрел на себя (сам федорой пол года пользовался).

Ушел лечиться.

Кстати, поводу сборки пакетов из unstable на stable. В бубнтодебиане очень быстро и часто меняется «формат» debian/rules, так туда добавляют кучу новых dh_ команд, которые отсутствуют в stable, поэтому создание бекпорта это тот еще геморрой. В rpm такого обычно нет.

В ведь в 2009-м году перед берлинской конференцией по packaging API они ещё только обсуждали, будут они их делать или нет, а у Nxx к этому времени они уже два года как работали и широко использовались.

ЛОЛ.

Скачай сам пакет от openSUSE 10.2, открой spec-файл и убедись.

http://ftp5.gwdg.de/pub/opensuse/discontinued/distribution/10.2/repo/src-oss/...

Более ранний выпуск в сети не нашел. openSUSE 10.2 - это 2006 год. http://en.wikipedia.org/wiki/OpenSUSE

Приходило. Но это не мешало мне их собирать.

Нет же. Такое бывает если набор репозиториев на сборочной машине не совпадает с моим

Ну так подключи те репозитории, относительно которых сервер собирает пакеты.

я привёл пример, который в rpm приводит к тому, что пакет поставить можно только с костылём

Ну ты можешь при установке просто указать «установить, не смотря на поломанные зависимости» и никакой разницы с дебианом не будет :-)

Ну посвяти меня в тайну того какие репы использует красношляпа для сборки своего дистра.

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

В этерпрайзе админы не ставят то что им захочется.
Ставят то что прикажут.
Это в шарашкиных конторах админы с котами в шредерах слово имеют.

Формат предоставляет для этого все возможности.

Еще раз: в deb НЕТ возможности сделать так, чтобы пакет ставился всегда, когда в системе есть все нужные для работы файлы и не ставился в другом случае. Или перечисляешь все известные тебе версии библиотек, с котрыми данный пакет работает вручную, или ты пишешь «>= (текущая версия)». В первом случае пакет будет ругаться на будущие и прошлые версии, даже если мог бы с ними работать, во втором случае он будет всегда ругаться на прошлые версии и никогда - на будущие. Хотя мог бы работать и с прошлыми возможно, не сможет работать с будущими.

Ну посвяти меня в тайну того какие репы использует красношляпа для сборки своего дистра.

openSUSE сама в себе и собирается. В красношляпе должно быть также.

Точно пора оттяпать от red hata кусок на благо человечества :0

Вдруг кто найдёт в этой документации упоминание мягких зависимостей — сообщите.

ЛОЛ. Документация от 2000 года. http://www.rpm.org/max-rpm/

12 лет назад написана :-)

Мое отношение к Ubuntu уже всем известно - закопать.

+1 (присоединяюсь)

Кстати, поводу сборки пакетов из unstable на stable. В бубнтодебиане очень быстро и часто меняется «формат» debian/rules

Обкурились?

http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules

«This file must be an executable makefile, and contains the package-specific recipes for compiling the package and building binary package(s) from the source.» (c)

«Просто makefile» - вот и весь «формат». Не обманывайте местных школьников!

так туда добавляют кучу новых dh_ команд

Не нравится debhelper/CDBS - не ешь, делай свои sh-велосипеды как в любимом интерпрайзу RH в каждом пакете (сюрприз!).

поэтому создание бекпорта это тот еще геморрой

Вы сколько штук бекпортов-то сопровождаете?

В космосе закапать нельзя ... ------------

закономерный результат, когда у debian срок поддержки всего года три, а у ubuntu - все десять!

Убубу везде хренова. Хоть на сервере, хоть на на десктопе.

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

Показательно, что если все версии xenserver-а, сам, sdk и ddk сделаны на центосе, а вот серверная виртуалочка synchronizer для xenclient уже идет на базе убунты...

«Просто makefile» - вот и весь «формат». Не обманывайте местных школьников!

я специально взял «формат» в кавычки

Не нравится debhelper/CDBS - не ешь, делай свои sh-велосипеды как в любимом интерпрайзу RH в каждом пакете (сюрприз!).

RH макросы в spec'ах от релиза к релизу так радикально не меняются. Какие-нибудь сложные пакеты типа петона собрать на старой деб-системе почти нереально.

Вы сколько штук бекпортов-то сопровождаете?

~10

Просто Дебиан очень хороший, а убунта дебьяно-подобна.

В этерпрайзе админы не ставят то что им захочется.
Ставят то что прикажут.

И, потом, это всё по тому приказу и работает. ;-)

Приказать правильно может только тот, кто разбирается. А это, считай, тот же админ, только уровнем повыше.

ибо альтовский rpm часто генерирует зависимости вида set:3f5b289c.

теперь всегда.

А rpm-пакеты можно поставить даже собранные 5 и 10 лет назад, и там будут
правильно зависимости разрешаться.

Ага. И будет писать «нельзя поставить, так как бла-бла.so.n нельзя установить». :-) Через 10 лет поставиться имеет шанс только статически собранный пакет.