Ubuntu наращивает долю на рынке крупных промышленных систем

Плохо...

молись

Зачем?
Кстати вопрос. Что дешевле РХ или абунта?

Никто не заставляет указывать >=. Можно указать точное соответствие.

Какой симлинк? Зачем? Ты сам то понимаешь что говоришь?

Медленно и печально:

Ты ставишь rpm-пакет, которому требуется libastral.so.2.0.1 (особенно этим любят увлекаться пакеты из Mandriva — прим. перев.). В системе есть libastral.so.2.0.5. Твои действия?

Вариант а) отказаться от установки из-за неразрешённых зависимостей. б) с матами переписать спек пакета, указав нормальную зависимость на libastral.so.2.0 или в) поставить с nodeps и сделать симлинк с libastral.so.2.0 на libastral.so.2.0.1 г) предложи свой

В rpm это решается 3'мя командами.

$ wget -c http://url/libwtf-1.0.0.src.rpm
$ rpmbuild -bb libwtf-1.0.0.src.rpm
$ rpm -Uvh ~/rpmbuild/RPMS/arch/libwtf-1.0.0.arch.rpm

Но в 99.99% случаев это не нужно именно благодаря файловых зависимостей.

Ну так, чисто случайно, пакет из федоры сможет поставиться в альте?

Смотря какой. Я ставил на альт некоторые пакеты из Suse и Fedora. Наоборот - уже сложнее, ибо альтовский rpm часто генерирует зависимости вида set:3f5b289c.

Ты во всех этих тредах официально представляешь батхерт зузеводов?

Если сборщик пакет не идиот, он не будет в зависимостях указывать полную версию пакета, благодаря чему системе подойдёт и -1, и -2.

То же самое и в rpm, кстати, сборщики идиоты попадаются.

А, тут же выясняют преимущества rpm перед deb, а не сборщиков перед сборщиками… :)

Если сборщик пакет не идиот, он не будет в зависимостях указывать полную версию пакета, благодаря чему системе подойдёт и -1, и -2.

Если он точно знает именно то множество версий другого пакета, с которым его пакет будет работать. Знает точно и наперед. Может предсказывать будущее. На практике дебиановцы просто пишут >= (текущая версия данного пакета), надеясь, что создатели пакета не поломают обратную совместимость в будущем. А если поломают, то будут глюки.

Ты не понел. Мне надо чтобы адекватно говорилась причина неустановки пакета. И вместо белиберды вроде

perl5(Apache) <= 1.2
Mail-Header >= 1.01
perl(Carp) >= 3.2
perl(IO-Wrap) == 4.5 or perl(IO-Wrap)-4.5

Чтобы показывал нормальное название пакета.

Ты ставишь rpm-пакет, которому требуется libastral.so.2.0.1 (особенно этим любят увлекаться пакеты из Mandriva — прим. перев.). В системе есть libastral.so.2.0.5. Твои действия?

Пакет не поставится.

с матами переписать спек пакета, указав нормальную зависимость на libastral.so.2.0

Зависимость генерится автоматически, поэтому rpmbuild -bb без всяких переписываний spec'ов.

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

Что значит fixed?

То же самое и в rpm, кстати, сборщики идиоты попадаются.

В rpm зависимости генерируются автоматом по именам слинкованных библиотек из бинарников. От сборщика не требуется предсказывать будущее и гадать на кофейной гуще: если ABI изменилось или нужный файл убрали из последующей версии, это сразу определит пакетный менеджер и не будет устанавливать несовместимый пакет.

ты не поверишь, но в том же urpmi можно указывать белиберду:

urpmi 'perl(Carp)' 'perl(IO-Wrap)'

не в курсе можно ли так делать в yum

значит, что ты %уйню сказал, а я на ней ответил %уйней

Я у себя в системах при сборке пакета как раз руками правлю зависимости, благодаря чему мои пакеты становятся и на чистый stable, и на stable c бекпортами, и на testing.

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

значит, что ты %уйню сказал, а я на ней ответил %уйней

Язабан.

И да, fixed

Дело не в сборщиках, а в принципиальных отличиях автоматической генерации зависимостей в deb и rpm.

Я имел ввиду сборку пакета с нуля и правку зависимостей после отработки автоматики.

А что касается пересборки или бекпортирования пакета(я так понимаю, именно это показано в трёх командах), в debian'е это делается точно так же, только как там выше уже говорилось, вместо одного src - три файла. Но действий столько же.

$ dch -i 
$ dpkg-buildpackge -rfackeroot
$ dpkg -i ../*.deb

Никто не заставляет указывать >=. Можно указать точное соответствие.

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

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

Можно. А как имя пакета то узнать? Информация потеряна. На этапе сборки рпм в котором появилась такая зависимость. Поэтому репа может быть неконсистентной. Тоесть некоторые пакеты из нее нельзя установить так как там есть зависимости от того чего в этой репе нет.

Говорит, что это гадание на кофейной гуще. Мейнтейнер надеется, что его программа будет работать со всеми последующими версиями пакета с таким именем, надеясь на обратную совместимость.

О, а ты вообще не в курсе политики именования пакетов, и почему оно всё же работает и не валится.

Лучше скажи мне, друг любезный, давно ли в rpm появились мягкие зависимости? Давно ли там стало возможно переконфигурировать пакет после установки?

А то производится впечатление, что rpm может всё, что может deb и немного сверху, что мягко говоря. неправда.

правку зависимостей после отработки автоматики.

Автоматика в deb работает настолько криво, что надо за неё подчищать руками?

Но действий столько же.

Скачивание «пакета», накладывание deb-патча, cd в директрию ... стыдливо упустил? Про «простоту» сборки deb'ов рассказывать мне не надо, ибо я занимаюсь этим каждый день и не по наслышке знаю какой это ад.

Это не косяк deb-формата. Если он формат пакетов позволяет сделать и так, и так, это только плюс. И да. Не всё так плохо в debian'е, иначе было бы очень тяжело смешивать на одной системе несколько разных веток дистрибутива. Но практика показывает, что это работает.

В rpm зависимости генерируются автоматом по именам слинкованных библиотек из бинарников.

Ну то есть они статические. ЧТД.

Вариант а) отказаться от установки из-за неразрешённых зависимостей. б) с матами переписать спек пакета, указав нормальную зависимость на libastral.so.2.0 или в) поставить с nodeps и сделать симлинк с libastral.so.2.0 на libastral.so.2.0.1 г) предложи свой

Дурачок! В спеках никто зависимости не пишет! Зависимости автоматически определяются по вызовам функций в бинарных файлах после сборки. Если в твоей системе нет того файла, с которым пакет был слинкован при сборке, то лучше всего его и не пытаться запустить, потому что это чревато крэшем.

Так что либо ищи пакет с тем файлом, который нужен твоему пакету, либо пересобирай с новыми либами.

И это правильно. В том же самом случае для деба ты пакет установить сможешь, но запустить не сможешь, так как он слинкован с libwtf.so.1.0.2, а в репозитории только libwtf пакет с libwtf.so.1.0.5.

Имя пакета по файлу узнается с помощью утилит дистрибутива. В Магии это делается с помощью urpmf.

Но практика показывает, что это работает.

Моя практика говорит, что это не работает или работает только для простейших вещей, типа программ, написанных на скриптовых языках.

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

Чтобы показывал нормальное название пакета.

Название пакета не содержит всей необходимой информации о его содержимом. Пакет может называться так, а содержимое может быть совсем другим. Или чуть-чуть другим. В rpm зависимости определяются точно. В дебиане - приблизительно (главное - поставить пакет с таким названием, а что там внутри - хз).

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

А ещё я там примеры про перл зависимости писал. Это что, имена файлов по твоему? Имхо это какаято редхатная приблудохрень сделанная непонятно зачем.

Автоматика в deb работает настолько криво, что надо за неё подчищать руками?

Я бы сказал иначе. Гибкость формата deb позволяет настроить множество вариантов, а автоматика предлагает самый простой.

Скачивание «пакета», накладывание deb-патча, cd в директрию ... стыдливо упустил?

Да, про apt-get source package_name и cd я забыл. Извиняюсь, я думал это само собой разумеется. А вот накладывать патчи руками не надо. Автоматика. :) Итого, на две не требующие внимания команды больше. В этом всё преимущество rpm над deb? :)

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

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

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

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

Если такое случилось в оф репозитории, то надо писать баг разработчикам. В 99.99% случаев это невозможно, а если случается, то кривой пакет ты установить не сможешь и это _правильно_. В дебе же ты никогда и не узнаешь о такой проблеме, точнее узнаешь, но когда будешь запускать программу, что очень и очень плохо.

А ещё я там примеры про перл зависимости писал. Это что, имена файлов по твоему? Имхо это какаято редхатная приблудохрень сделанная непонятно зачем.

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

Вернее понятно зачем. Для кроссдистрибутивности. А ее нет по факту. И никогда не было.

Можно. А как имя пакета то узнать?

ЛОЛ. Зачем тебе имя пакета? Пакетный менеджер знает, какие пакеты что предоставляют.

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

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

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

Какой apt-get source? Если в дебе подключить unstable, то это развалит полсистемы, поэтому его не подключают и apt-get source не работает.

В 99.99% случаев это невозможно

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

В дебе же ты никогда и не узнаешь о такой проблеме.

Пруф, блджад!

В дебе не встречаются зависимости от файлов. Поэтому не может быть такого что пакет поставился а файла по факту нет. Так как зависимость в виде имени пакета появляется на этапе сборки деб пакета. Редхат же себя не утруждает этим как правило.

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

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

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

Может быть. Программа слинкована с libwtf.so.1.0.0 в дистрибутив залили пакет libwtf_1.0.1 (с файлом libwtf.so.1.0.1), а пакет libwtf_1.0.0 удалили. В итоге зависимостям мы удовлетворяем (привет дебиановскому ноухау с >= (1.0.0) :) ), но ничего не работает.

Дурачок! В спеках никто зависимости не пишет!

Сам дурачок.

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

Интересно, как система автоматически определит, что мне нужна библиотека версии 2.0.x, где x—любое число? Допустим, разработчики меняют только производительность в рамках минорных изменений, да накладывают security пачти. Правильно, никак. Поэтому спеки можно поправить. Обычно это делается так — симлинк от libastral.so.2.0. на libastral.so.2.0.5, как я писал уже выше. Обновляешь libastral до 2.0.6, симлинк остаётся, все пакеты довольны. А автоматически у тебя пропишется 2.0.5 и при первом же багфиксе пакет удалится.

О, а ты вообще не в курсе политики именования пакетов, и почему оно всё же работает и не валится.

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

libastral.so.1.3 libastral-mt.so.1.3

Теперь ABI одной из них изменилось. Стало

libastral.so.1.3 libastral-mt.so.1.4

Если игре нужна только либа libastral.so.1.3, то на rpm-дистре она будет работать и с новым пакетом. А на deb в соответствии с правилами (и если мейнтейнеры не совсем придурки), пакет с либой будет переименован и данная игра будет ругаться на зависимости.

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

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

Пропишется так как скажет ldd

Debian Squeeze. В нём установлен postgresql-9.0.1, итон 2.7 как основной и третий в alternatives, последний nginx из sid'а и несколько небольших пакетов из бекпортов. Это простейшая конфигурация? Из самой стабильной ветки софта тоже достаточно.

Понятное дело, что данная конфигурация совершенно нестандартна и я до сих пор не понимаю программистов, из-за проекта которых мне пришлось такое настроить, но всё это сделано штатными средствами debian'а. Всё в рулится пакетным менеджером, всё, кроме третьего питона обновляется apt-get'ом без пересборки.

Это не косяк deb-формата. Если он формат пакетов позволяет сделать и так, и так, это только плюс.

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

Ну то есть они статические. ЧТД.

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

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

Ну а если уж лениво в sources.list прописывать что-то, то всегда есть dget.

Ключевое слово _из_ _бекпортов_. Я сидел на мандриве 2008.1 до выхода 2010, при этом ставил нужные пакеты из кукера без обновления полсистемы и всё работало. Такое дебиану с его идиотскими зависимостями и не снилось.

Может быть. Программа слинкована с libwtf.so.1.0.0 в дистрибутив залили пакет libwtf_1.0.1 (с файлом libwtf.so.1.0.1), а пакет libwtf_1.0.0 удалили. В итоге зависимостям мы удовлетворяем (привет дебиановскому ноухау с >= (1.0.0) :) ), но ничего не работает.

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

А про лдконфиг и версии библиотек не слыхал? Линковать надо правильно. Что все и делают. Симлинки видел в /lib ?

Так что твоя причина надуманна именно тобой.