Google выбирает Ubuntu

не выдерживает критики. Файловые зависимсти не являются решением задачи (так же, как и пакетные); оба вида зависмостей решают задачу частично.

Пакетные зависимости не решают задачу вообще, даже частично

Укажи зависимость руками, в чем проблема?

И так для каждой из 100500 библиотек? А если я перейду на новую версию библиотеки где сменился ABI опять руками лезть в control файл? Ну нафиг!

Не могу, потому что при нажатии например хрома в метро открывается метро-версия хрома, неправильный пуск

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

Обычно если пакетный менеджер предлагает снести/переустановить пол системы ради одного пакета, это хороший индикатор того, что ты пытаешься поставить какой-то явно не тот пакет.

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

Для создания deb нужно написать около десятка отдельных файлов, которые кладутся в папку CONTROL.

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

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

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

Что такое, AutoReqProv отменили, секцию Requres тоже? Ладно, смотрим, например, mod_python-3.3.1-17.fc17.i686.rpm; видим там (помимо файловых зависимостей):

httpd >= 2.0.40

Внезапно, httpd - это пакет, httpd-2.2.22-4.fc17.i686.rpm. Считаем доказанным фактом, что пакетные зависимости в RPM есть и используются. Теперь идем в mod_python-3.3.1-17.fc17.src.rpm и видим там:

Requires: httpd >= 2.0.40

Считаем доказанным факт ручного прописывания зависимостей. Поздравляем вас, гражданин, соврамши.

А в DEB мейнтейнеры сами вольны давать имена пакетам

ROTFL. А в RPM, значит, имена пакетам дает не мэйнтейнер, а... кто? ТНБ? Леннарт лично?

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

Зависит.

А на rpm - установится, лишь бы там были нужные(слинкованные) файлы.

Ты знаешь об RPM гораздо меньше, чем тебе кажется.

Да мне не все равно, как там эта папка называется? Главное, что в .dsc идет архив с папкой, в которой инструкции для сборки, но без исходников и патчей. А исходники идут в отдельных тарболах, и патчи тоже отдельно, как правило, одним огромным диффом вместо того, как в rpm - по диффу на патч. И того, для сборки одного пакета в дебиане надо таскать минимум, три файла, а как правило, намного больше.

Файловые зависимсти не являются решением задачи (так же, как и пакетные); оба вида зависмостей решают задачу частично.

Пакетные зависимости не решают задачу вообще, даже частично

Ты говоришь это пользователю Debian, для которого пакетные зависимости эту задачу как раз решили (частично).

Укажи зависимость руками, в чем проблема?

И так для каждой из 100500 библиотек?

Тебе не угодишь - автоматическое указание зависимостей не подходит, ручное - тоже.

Что такое, AutoReqProv отменили

Да. Оно и так включено по умолчанию всегда.

Считаем доказанным факт ручного прописывания зависимостей.

ЛОЛ. Ты, похоже, читать не умеешь. Автоматически прописываются зависимости от слинкованных библиотек. Это 90% всех зависимостей. А если программа вызывает какую-то другую из командной строки или через dbus, или использует файл данных другой программы, или еще какой-нибудь экзотический случай - это совсем другое дело.

ROTFL. А в RPM, значит, имена пакетам дает не мэйнтейнер, а... кто? ТНБ? Леннарт лично?

В RPM имя пакета может быть любым, это на зависимости не влияет.

Тебе не угодишь - автоматическое указание зависимостей не подходит, ручное - тоже.

автоматическое в стиле rpm подходит

Считаем доказанным факт ручного прописывания зависимостей.

ЛОЛ. Ты, похоже, читать не умеешь.

Не-а. Это ты написал:

Nxx> все зависимости генерируются автоматически и там не может быть никакой самодеятельности

А я тебе привел пример зависимости, прописанной вручную.

В RPM имя пакета может быть любым,

В dpkg тоже.

это на зависимости не влияет.

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

Да мне не все равно, как там эта папка называется?

Это просто показывает, что про сборку пакетов deb-пакетов было услышано вскользь, на каком-то форуме, и разобраться, что же это такое, возможности не было. Остальные предположения по поводу того, что там за файлы идут в исходниках - из той же серии. Я тут себе чуть нос фейспалмом не сломал, пока всё это читал. Я серьёзно, стоит лучше ознакомиться с процедурой сборки и форматами исходников, чтобы не говорить, что «Говно эти ваши Биттлз, мне Рабинович вчера по телефону напел».

автоматическое в стиле rpm подходит

Тяжелый случай синдрома утенка.

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

Ну ты, похоже, правда, тупой. Еще раз прочитай, что я писал:

Google выбирает Ubuntu (комментарий)

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

Я серьёзно, стоит лучше ознакомиться с процедурой сборки и форматами исходников, чтобы не говорить, что «Говно эти ваши Биттлз, мне Рабинович вчера по телефону напел».

Просто «ознакомиться» маловато будет - пациент действующий сборщик RPM, но от его заявлений насчет RPM у меня лицо в синяках от фейспалмов.

Нет, просто подход rpm объективно лучше.

Ну ты, похоже, правда, тупой.

Тупой не я, а ты. А еще у тебя баттхерт.

Еще раз прочитай, что я писал:

Google выбирает Ubuntu (комментарий)

Ичо?

Nxx> Сейчас зависимости определяются по линковке.

Ну да, тут не написано, что «все зависимости». Про «все зависимости» и «никакой самодеятельности» написано тут: Google выбирает Ubuntu (комментарий)

Ты специально вырезаешь из моих постов фразы «в большинстве случаев» и «для программ, написанных на Си и еще нескольких языках» ?

Ты реально хочешь мне что-то приписать, и в чем-то обвинить да?

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

подход rpm объективно лучше.

Хотел спросить про «объективные» критерии, но потом понял, что ты уже приводил один и сам RPM ему не удовлетворяет.

Ты специально вырезаешь из моих постов фразы «в большинстве случаев»

Мля. Вот твоя фраза:

Nxx> В RPM все зависимости генерируются автоматически и там не может быть никакой самодеятельности.

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

для программ, написанных на Си и еще нескольких языках

Ты не поверишь - mod_python написан на Си и при этом зависимость на httpd прописана вручную и по имени пакета.

Ты реально хочешь мне что-то приписать, и в чем-то обвинить да?

Тебе лично? Нет, зачем ты мне нужен. Я хочу сказать, что RPM не так сильно отличается от deb, как ты пытаешься представить.

Удовлетворяет. Зависимости в rpm гораздо мягче.

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

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

Удовлетворяет.

А, ну да - RPM удовлетворяет объективному критерию «наличие файловых зависимостей». Здесь ничего не скажешь - удовлетворяет. Правда, необходимость файловых зависимостей не доказана, убедительных примеров ее полезности не приведено.

Все, что я хотел сказать, написано выше.

Ага, и я привел нужные цитаты.

Я четыре вида мягкости зависимостей, кроме как в .deb, нигде не видел.

А, ну да - RPM удовлетворяет объективному критерию «наличие файловых зависимостей». Здесь ничего не скажешь - удовлетворяет. Правда, необходимость файловых зависимостей не доказана, убедительных примеров ее полезности не приведено.

Посмотри в архивах лора. Там куча примеров приведена.

Я четыре вида мягкости зависимостей, кроме как в .deb, нигде не видел.

RPM: suggests, enhances, recommends, supplements

Но резет говорил не об этом, а о том, что в дебиане жестко прописывается версия библиотеки, которая требуется для пакета, как правило, >= (версия на системе сборки), поэтому с более старой библиотекой пакет не установится, даже если на самом деле, мог бы нормально с ней работать.

Обычно если пакетный менеджер предлагает снести/переустановить пол системы ради одного пакета, это хороший индикатор того, что ты пытаешься поставить какой-то явно не тот пакет.

я в курсе. Но этот пакет прислали из репозитория.

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

угу. «ты» ты зря написал. Я не джедай.

еще раз — файловые зависимости влекут мягкие автоматические зависимости и уменьшение геморроя как для пользователя при установке пакета из другой ветки репозитория так и для разработчика при сопровождении пакета

Я не про suggest/recomments и т.п. В rpm оно тоже есть.

я в курсе. Но этот пакет прислали из репозитория.

Как это «прислали»? Даже если он был в репе, это не значит, что его надо сразу ставить, не глядя на вывод пакетного менеджера.

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

угу. «ты» ты зря написал. Я не джедай.

Для этого не надо быть джедаем. Это делается вполне стандартно.

еще раз — файловые зависимости влекут мягкие автоматические зависимости

Слова, слова...

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

Приведи уже нормальный пример.

Я не про suggest/recomments и т.п. В rpm оно тоже есть.

Что, уже и Recommends есть? Хорошую идею из dpkg грех не стырить %)

Приведи уже нормальный пример.

Вышел релиз Ubuntu «Lucid Lynx» 10.04 LTS (комментарий)

Что, уже и Recommends есть? Хорошую идею из dpkg грех не стырить %)

Оно есть примерно 10 лет уже. ЛОЛ. Тебе сколько лет было, когда его не было?

Как это «прислали»? Даже если он был в репе, это не значит, что его надо сразу ставить, не глядя на вывод пакетного менеджера.

в мандриве есть какая-то хрень, которая каждые 3 часа проверяет новые файлы в репозитории, и ставит их автоматически. По дефолту работает. Как отключается - я не знал. Я даже не знал, что она вообще есть.

Кстати, если что-то есть в репе, но это что-то не надо ставить «не глядя», то за кой леший мне вообще ваши суси/бубунты? Я слаку поставлю, там всё тоже самое, и плюс нет гемороя с зависимостями (за неимением оных).

Пакетный менеджер должен работать САМОСТОЯТЕЛЬНО, а я, тупой юзверь, должен тупо на него смотреть. А если я не тупой юзер, и умею читать чейнджлог и делать diff&patch, то за кой мне этот ваш ПМ?

Так вот: aptitude - подошла ближе к идеальному ПМу, а от rpm проблем больше, чем их решений. ИМХО лучше совсем отказаться от ПМ, чем юзать этот ваш кривой rpm.

Для этого не надо быть джедаем. Это делается вполне стандартно.

давеча обновлял ленни на сквиз. В первый раз ничего не получилось - проблема в том, что я обновлял US версию с RU зеркала. А там ВНЕЗАПНО нет переводов en_US (sic!). Ладно, переписал зеркало на US, обновил. С ТРЕТЬЕГО раза - какие-то проблемы с закачкой. ИЧСХ, если скачать каталог на 100500 файлов, или там образ на 8Гб, то никаких проблем с моей связью нет. А вот пакеты от дебиана качаются с какими-то непонятными проблемами. ЧСХ, если такая проблема есть, то нужно всё начинать с начала. Хотя я делал всё вполне себе стандартно... Обновить слакварь в разы легче и быстрее.

Например, у тебя стоит glib-2.32.0 и программа A, которая его использует. В unstable glib-2.32.4 и новая мажорная версия программы A, которая с ним слинкована. При смене glib-2.32.0->2.32.4 ABI сохраняется, поэтому зависимость остается прежней и я без геморроя ставлю программу A из unstable. В дебобунте зависимость меняется, поэтому я имею геморрой.

Кстати, если что-то есть в репе, но это что-то не надо ставить «не глядя», то за кой леший мне вообще ваши суси/бубунты?

Ну вот, например, в репе есть пакеты для i586. А у меня система 64-битная. Значит ли это, что я должен не глядя ставить из репа пакеты для другой архитектуры?

Что, уже и Recommends есть? Хорошую идею из dpkg грех не стырить %)

Оно есть примерно 10 лет уже. ЛОЛ.

Лгешь. 10 лет назад был только Recommends.

Тебе сколько лет было, когда его не было?

Думаю, больше, чем тебе теперь.

Например, у тебя стоит glib-2.32.0 и программа A, которая его использует. В unstable glib-2.32.4 и новая мажорная версия программы A, которая с ним слинкована. При смене glib-2.32.0->2.32.4 ABI сохраняется, поэтому зависимость остается прежней и я без геморроя ставлю программу

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

Ну вот, например, в репе есть пакеты для i586. А у меня система 64-битная. Значит ли это, что я должен не глядя ставить из репа пакеты для другой архитектуры?

э... ваш пакетный менеджер уже не в состоянии распарсить архитектуру? тяжёлый случай...

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

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

и ставит их автоматически.

а такого нет

Я слаку поставлю, там всё тоже самое, и плюс нет гемороя с зависимостями (за неимением оных).

потому что эта проблема переложена на пользователя

и ставит их автоматически.

а такого нет

...потому-что эта проблема ложится на пользователя.

Я слаку поставлю, там всё тоже самое, и плюс нет гемороя с зависимостями (за неимением оных).

потому что эта проблема переложена на пользователя

где ты видишь «проблему»? проблемы-то нет: если новый пакет A зависит от B, C, D, то Патрег пересобирает A, B, C и D. Вот и всё. А пользователь ставит все эти 4 пакета и не расстраивается... В чём проблема?

где ты видишь «проблему»? проблемы-то нет: если новый пакет A зависит от B, C, D, то Патрег пересобирает A, B, C и D.

забыл сказать, если юзеру не нужен пакет D, то он и НЕ поставится. Обновятся только установленные пакеты A, B, C.

...потому-что эта проблема ложится на пользователя.

какая проблема?

где ты видишь «проблему»? проблемы-то нет: если новый пакет A зависит от B, C, D, то Патрег пересобирает A, B, C и D. Вот и всё. А пользователь ставит все эти 4 пакета и не расстраивается...

А то что надо поставить эти 4 пакета пользователь узнает, используя libastral.

какая проблема?

что ставить, а что не ставить. И в слаке эта проблема решена - можно и нужно ставить всё подряд. То, чего нет, то и не поставится. Как и то, что для другой архитектуры.

А то что надо поставить эти 4 пакета пользователь узнает, используя libastral.

зачем «libastral», есть ведь простая электронная почта (в самом примитивном случае).

вот например:

New slocate packages are available for Slackware 12.1, 12.2, 13.0, 13.1, 13.37,
and -current to fix a security issue.


Here are the details from the Slackware 13.37 ChangeLog:
+--------------------------+
  Patched to use lstat64 and -D_LARGEFILE64_SOURCE.  Thanks to Mancha+.
  Patched to fix information leak of filenames in protected directories.
  For more information, see:
    http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0227
  (* Security fix *)
+--------------------------+


Where to find the new packages:
+-----------------------------+
...

А как это в твоём любимом дистре?

или просто его ломает читать этот __бред__.

это ключевое слово

А как это в твоём любимом дистре?

sudo urpmi --auto --auto-update

и всё делается само

И в слаке эта проблема решена - можно и нужно ставить всё подряд. То, чего нет, то и не поставится. Как и то, что для другой архитектуры.

Бугога. Не зря говорят, что шлака — помойка.

sudo urpmi --auto --auto-update

и всё делается само

в слаке тоже есть такая команда. Есть и slaptget upgrade типа как в дебиане. Т.ч. не принимается.

И в слаке эта проблема решена - можно и нужно ставить всё подряд. То, чего нет, то и не поставится. Как и то, что для другой архитектуры.

Бугога. Не зря говорят, что шлака — помойка.

это ты к чему? помойка - у тебя, где надо голову ломать, что можно ставить, а что не нужно. А что можно, только пол-дистра снесёт нах.

Замечательно. А как мне поставить одну программу и все её зависимости, если таковых нет?

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