Он ищет самую младшую подходящую.

Ну допустим, младшую подходящую он найдет, перперыв репы всех старых релизов. Как он определит самую старшую подходящую?

Ну, по крайней мере, libc, libc4, libc4_4, libc5, libc5_4, libc5_5 у них было.

Тогда где брать версию пакета?

Еще раз, медленно и печально: база с версиями пакетов генерируется один раз и распространяется в готовом виде. При генерации может использоваться содержимое archive.debian.org

Оно не сломалось, оно просто не работает

В какой-то из многочисленных Вселенных в Debian и Ubuntu не работает управление пакетами? Перебирайтесь в нашу, у нас всё нормально.

При генерации может использоваться содержимое archive.debian.org

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

Помучиться пришлось только подопытным кроликам, использующим Федору.

Я наоборот получил наконец-то Федору, которая работает с одной только KDE, не притягивая в инсталляцию половину GNOME-пакетов даже, если мне нужно использовать пару-тройку Gtk-программ.
Никаких мучений. Надеюсь теперь не придётся ставить Mate вместе с KDE.

Лор - сборище даунов.

http://en.wikipedia.org/wiki/GNU_C_Library

In the early 1990s, the developers of the Linux kernel forked glibc. Their fork, called «Linux libc», was maintained separately for years and released versions 2 through 5.

Когда glibc будет портирован на illumos, не удивлюсь, если его soname будет libc.so.2

Уважаемый, а поведайте историю libc.so.6

Честно говоря, я ее и сам не знаю (версии 1-4 были до того, как я начал пользоваться Linux). AFAIK, версии 1-5 были форком GNU libc 1.0, libc5 была первой ELF-версией, а libc6 - это GNU libc 2.0.

К тому же, в glibc не одна только либа, а несколько. Некоторые из них мало используются и могут быть выкинуты в будущих версиях. Опять Дебиан должет будет переименовывать пакет. А в suse эти либы просто попадут в отдельный пакет glibc-obsolete и те программы, которым они нужны, будут этот пакет устанавливать по зависимостях, в дополнение к новому glibc.

Да, да. А еще при выкидывании GLIBC_2.2.5 этого никто не заметит.

И запишет туда libwtf (>= 1.0.1), а в libwtf (>= 1.1.0) сломается ABI и всё перестанет работать.

Нет. Но всё же просвети нас, каким волшебным образом в RPM ничего не сломается?

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

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

Ты ж, вроде, умный человек.

Если авторы libwtf такие дауны (что бывает), то в Дебиане сделают:

пакет libwtf1.0 с libwtf.so.1.0 и пакет libwtf1.1 с libwtf.so.1.1.

Новые софтины будут плавно портироваться на 1.1, а старые продолжат работать со старой библиотекой.

Посмотри на libv8-a.b.c.d и на libsslX.Y.Z.

Нет.

да

Но всё же просвети нас, каким волшебным образом в RPM ничего не сломается?

В rpm при установке libwtf версии >= 1.1.0 возникнет конфликт, в результате которого пользователю или придется снести пакет либо не обновлять libwtf.

Если авторы libwtf такие дауны (что бывает), то в Дебиане сделают:

этот костыль я выше упоминал

Нет.

да

Нет. И тебе уже объяснили, как именно обрабатывааются подобные ситуации.

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

О да, конечно. На любой репозиторий Васи - отдельную базу и подключать ее при сборке пакетов Дебиана. лол.

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

На любой репозиторий Васи - отдельную базу и подключать ее при сборке пакетов Дебиана. лол.

Ну то есть насчет Убунты вопросов нет - уже хорошо. Насчет «репозиториев Васи» - если они есть в сети, никаких проблем.

Спасибо, Nxx. Теперь из-за тебя, я буду ждать этого релиза как никогда ранее...

Не работают они только в openSUSE 12.3 milestone. А не в 12.2.

Расскажи, чем именно обработка зависимостей в apt неадекватна.

Тем, что в apt зависимость идёт сразу на пакет, а в rpm — сначала на библиотеку, а только потом на пакет. Можешь посмотреть, скажем, man urpmi для деталей

Подтверждаю, у меня в 12.2 Huawei E303 сам определился

Не скажите, для нас (КДЕ-шников) только в радость, что гном скатился сами знаете куда...

Расскажи, чем именно обработка зависимостей в apt неадекватна.

Тем, что в apt зависимость идёт сразу на пакет, а в rpm — сначала на библиотеку

И? Неадекватность-то в чем?

man urpmi для деталей

Я 10+ лет работал на Redhat (причем начинал, прикинь, с apt-rpm), почти 4 - на Debian, собрал кучу пакетов для обеих систем. Посылы к манам можешь пропустить, переходи к делу.

твои хваленые mageia/fedora уже научились гибким зависимостям?

в Fedora, как уже написали выше, не используется, но есть, а в urpmi это ещё, ЕМНИП, добавили во времена Mandrake, кстати, pacman это тоже умеет (по крайней мере, 3.4.х умел 100%)

Нет гибкости в зависимостях, вот и всё. Если я хочу conky, то это не значит, что я хочу lua, но apt тянет ещё lua со своим паровозиком зависимостей в придачу. Извините, но в жопу такой пакетный менеджер

Правда «залипает» переключалка

Исключительно в области скайпа у меня такое встречается.

Нет гибкости в зависимостях, вот и всё

В dpkg гибкие заивисимости, и они реально используются.

Если я хочу conky, то это не значит, что я хочу lua

Причем здесь твое желание? Если lua необходим для conky - значит, так решил автор conky, предъяви претензии ему. Если lua не необходим - значит, читай маны насчет --no-install-recommends.

Извините, но в жопу такой пакетный менеджер

Посылать других ты уже научился - теперь пошли сам себя... почитать маны.

Ubuntu не Linux, XoFfiCEr не человек

Ага, слышали уже.

Они же вроде бы взяли кодовую базу гнома и немного допилили. И все.
Надо будет только имена некоторых конфигов поменять и вперед.
Кардинально (кроме названия) там ничего и не изменилось.

в Fedora, как уже написали выше, не используется, но есть

ещё скажи, что это «ненужно!»

Если я хочу conky, то это не значит, что я хочу lua, но apt тянет ещё lua со своим паровозиком зависимостей в придачу.

уж не федороводу об этом говорить, особенно в свете сказанного выше

не используется

Я наоборот получил наконец-то Федору, которая работает с одной только KDE, не притягивая в инсталляцию половину GNOME-пакетов даже, если мне нужно использовать пару-тройку Gtk-программ.

что, серьёзно? Они это наконец сделали?

Хм...

А с каких это пор RHEL вообще можно обновить с ветки на ветку?

для нас (КДЕ-шников) только в радость, что гном скатился сами знаете куда...

Спрашивается, а не похер ли вам должно быть?..

Еще с 17й где-то так:

$ rpm -qa \*gnome\* | wc -l 15

Из независимостей там wireshark-gnome

После того, что творилось с выходом кед 4.0 — да как-то не очень.

XoFfiCEr не человек

Я такого не писал :)

И что же, все это будет делаться автоматически при обновлении дистра?

ура MATE будет жить

Много раз говорили, почему deb дистрибутивы более живучие и распространённые:

• Паковать в deb для непрофессионалов проще, значит будет гораздо больше ПО (авторы программ сами их запакуют).
• У Убунты есть централизованный метод строить свои репы: ppa, это оказывается удобнее, чем некий реп сообщества, потому что в ppa ты сам себе хозяин. Как следствие больше программ.
• В Убунте/Дебиане больше программ, потому простые пользователи и разработчики специализированного софта предпочитают их, поэтому программ там становится ещё больше.

Проблема rpm в том, что там следить за софтом могут только хорошо подготовленные спецы, иначе все сила и красота rpm не окупится и всё будет печально. Спецов мало и они денег хотят. А в deb-ы умеют паковать простые смертные.

В dpkg гибкие заивисимости, и они реально используются.

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

Вот выпустят RHEL7 и посмотрим. Зачем гадать?

Годнота.

Просто интересно, возможно ли это в принципе с yum.

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

Да, мне кажется, что им удалось. (мне самому верится с трудом, но факт - KDE не «гномится» - KDM не заменяется на GDM и т.п.) Пардон, не вспоминаю какие программы Gtk-шные, но я поставил свой обычный рабочий набор, который раньше однозначно притягивал половину Gnome-пакетов, а порой даже и попросту по зависимости приглашал неспосредственно весь Gnome (т.е. в какой-то момент с удивлением обнаруживаешь, что у тебя установлен Gnome и ты в него можешь войти, хотя его непосредственно и не ставил).

Правда я ставил (с DVD) экзотично: выбрал «графическую систему», включил KDE, выключил Gnome, поудалял 85% «системных» пакетов (раздел «системные» или типа того), которые мне не были нужны (среди них какие-то начинались на «gnome-» или «gtk» - сейчас не помню точно - вот им принципиально отказал). После установки, подлючился к Сети, обновил всё и только потом доустановил рабочие программы. Что-то с приставкой «gtk» появилось, но в единичных экземплярах, не так как раньше.

Пожалуй, соглашусь.

Я, как подопытный кролег, пострадал не сильно))

мелочное

Капиталисмус патамуша

У меня Centos 6.3 с KDE 4.3. В следующем году я обновлю его до Centos 7 c KDE 4.9 или даже 4.10. И мне глубоко наплевать на Гном2, Гном3, MATE, Cinnamon и прочий зоопарк. Когда я ставил себе веб-сервер в 2008 году, я выбрал Centos 5.2 и рабочий стол KDE 3.5.4. С тех пор мой сервак крутится и обновляется без проблем, хотя ради накатывания новых версий его пару раз пришлось ребутить. Так вот, рабочий стол у меня на удивление консистентен все эти годы. Строгий стройный интерфейс, где всё на своём месте. KDE4 теперь айс, он не тормозит. А если отключить индексирование папок и эффекты - то летает побыстрее гнома2. Я с самого начала прозревал, что ваш Мигель де Икаса - пи**рас, и что от его выпендрёжа рано или поздно пострадают все гномоводы. Так оно и случилось. Mate им теперь подавай... А ничего, что там все названия приложений поменялись? У юзера взорвётся мозг от всякой «кахи» (caja) вместо привычных имён.

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

Это да, я помню времена когда убунта ничем не отличалась кроме большого комьюнити и попыток сделать то самое юзерфрендли. Закрытые дрова помню даже ставить нормально не могла, всё надо было скрипты или поделки доставлять, вроде бы банальщина а долго оно сделать не могли. Апдейты имели свойство масово ломать всё к хуям. Имело смысл сидеть только на лютом стейбле. Ну и тормоза, делали на удивление тормознутую систему, firefox в те времена просто летавший на дебиане на убунте дичайше лагал и это длилось годами, релиз за релизом основной браузер был слайдшоу и марку было накласть у них видимо топовые видяшки были. Так что да, не таким уж и говном она стала недавно, но потом то кнопки переместили, то юнити и опять лаг на лаге баг на баге.

Спасибо, Nxx. Теперь из-за тебя, я буду ждать этого релиза как никогда ранее...

Не жди. Они уже давно лежат в updates 17-ой.