Gentoo

1. Размаскировкой нужных пакетов и зависимостей. Либо autounmask, либо вручную правкой /etc/portage/package.keywords или .unmask

2. Если pr_a-1 работает с lib-2, то просто установка pr_a-1 с маскировкой pr_a-2. Если pr_a работает только с lib-1, то либо установка lib-1, либо (если pr_b-2 требует lib-2) установка в слот двух либ (lib-1 и lib-2).

установка в слот двух либ (lib-1 и lib-2).

Да этот случай, установка двух версий либ как реализовано?

deb-based:
1. apt-get install -t testing some_program
2. не понятно, работает ли pr_b-2 с lib-1? Если да, то оставить lib-1 и pr_b-2 и любую из pr-a на выбор

Интересует вариант когда разные программы требуют разные версии библиотек. a - 1, b -2.

В gentoo проще всего - есть слоты
А так легче всего поставить lib-2 и prg_b-2 в ~, /opt, /usr/local
Можно посмотреть http://www.linuxfromscratch.org/lfs/view/stable/chapter06/pkgmgt.html

В FreeBSD нету такого кошмара.

>1. Есть несколько репозитариев

Нету никаких репозиториев. Есть FTP-сервера с собранными с дефолтными опциями бинарными пакетами из портов. Поддерживаются отдельные каталоги бинарных пакетов для -RELEASE и для -STABLE. Последние обновляются непрерывно — помере обновления дерева портов.

2. Есть программа pr_a, pr_b и библиотека lib. Допустим стояло у вас pr_a-1, pr_b-1 и lib-1. После апдейта стало: pr_a-2, pr_b-2, lib-2. Но pr_a-2 не работает с lib-2 по некоторым причинам. Хочется чтобы было pr_b-2 и pr_a-* (любой). Как это сделать?

Не бывает такого.
Дерево портов FreeBSD в любой момент времени обещает правильный граф зависимостей между программами и библиотеками. Другое дело, что человеческий фактор в лице мантейнеров портов не всегда успевает эти обещания претворить в жизнь. По возможности косяки устраняются в течение нескольких часов. Что-то не собирается и/или просит другую библиотеку, то варианты:
1) ССЗБ;
2) система устарела;
3) не обновил дерево портов;
4) не прочитал /usr/ports/UPDATING на предмет разруливания этого случая;
5) см. п.1).
Сценарии дерева портов гарантируют правильную сборку порта и всех его зависимостей согласно опциям сборки. Работоспособность ПО, собранного из порта, на совести автора приложения и мантейнера, который сопровождает порт.

Это понятно. Интересует как система будет пытаться разрешить конфликты.

Нету никаких репозиториев.

Один единственный или нету вообще?

Debian

1. backports или apt-pinning

2. E: Сломанные пакеты. В stable такого быть не должно, в testing можно откатиться или сделать ещё что-либо.

>Интересует вариант когда разные программы требуют разные версии библиотек. a - 1, b -2.

На FreeBSD по возможности ставятся обе библиотеки. Ссылочную (символическую) целостность обеспечивает сценарий установки порта. Если библиотеки уникальны (то есть должны присутствовать в системе в единственном экземпляре), то вопрос о предпочтительности программ, от неё зависимых, в дереве портов решается мантейнерами.

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

Альтернативные ветки зависимостей могут сосуществавать: например, можно установить и KDE 3.5 и KDE4. Одновременно можно использовать приложения и на Gtk1, и на Gtk2. Они не конфликтуют.

Нету вообще, если не считать зеркала официальных FTP-серверов с каталогами бинарных пакетов. Но ведь никто не называет репозиторием каталог FTP-сервера.

Slackware

Ситуация аналогичная описанной iZEN'ом: есть сравнительно небольшой репозиторий бинарных пакетов, который нельзя обновить так чтобы возник конфликт библиотек. Есть SBo который тоже консистентен в любой момент времени. Откатываться некуда. Только вперёд к коммунизму. Соответственно:
1) wget pkg_url; installpkg pkg_nam;
2) Не бывает в рамках работы с репами. Свои пакеты сопровождаешь как хочешь.
P.S: Я знаю что это несколько архаично, но в ситуации когда тебе нужно иметь три версии одного компилятора и пять разных сборок одной библиотеки ничего столь же простого в обращении и безотказного не придумали.

Fedora

1. # yum install что-нибудь --enablerepo=*testing

2. Неработоспособность пакета (установленного родных из репозиториев) после обновления — повод писать bug report

apt использует топологическую сортировку списка пакетов, затем вызывает dpkg для установки.

1. apt-pinning для apt и yum includepkgs для yum. Явно указывать репозитарий каждый раз — !Ъ, ибо гемор при обновлении (задолбаешься cron-apt'у и yum-updatesd объяснять, что именно имел в виду).
2. Правильная настройка п. 1.

> yum includepkgs

Н-да, отстал я от жизни. Не знал о таком, спасибо

// ушел перечитывать man yum.conf

Да этот случай, установка двух версий либ как реализовано?

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

[I] sys-devel/gcc
     Available versions:  
        (2.95)  2.95.3-r9 ~2.95.3-r10!s
        (3.1)   3.1.1-r2
        (3.2)   **3.2.2!s 3.2.3-r4
        (3.3)   ~3.3.6-r1!s
        (3.4)   3.4.6-r2!s
        (4.0)   ~*4.0.4!s
        (4.1)   4.1.2!s
        (4.2)   ~4.2.4-r1!s
        (4.3)   4.3.2-r3!s ~4.3.2-r4!s ~4.3.3-r2!s 4.3.4!s
        (4.4)   ~4.4.1!s ~4.4.2!s ~4.4.3-r2!s
        (4.5)   [M]**4.5.0!s

Правильное именование библиотек и не допущение коллизий - на совести разработчика ебилда (но механизм collision protect может помочь в детектировании проблемы с коллизией)

Постоение графа зависимостей на основе информации о слотах и других зависимостях - на совести пакетного менеджера.

Выбор версии по умолчанию - пишется скрипт для eselect, и через него всё разруливается симлинками. Получается вот так:

$ eselect python list
Available Python interpreters:
  [1]   python2.4
  [2]   python2.5
  [3]   python2.6 *
  [4]   python3.1

s/Одновременно могут стоять пакеты только из разных слотов./Одновременно могут стоять версии только из разных слотов./
s/Постоение/Построение/

>Как ставите все проги из stable, а лишь некоторые пакеты из testing'а?
Либо включаю testing на время установки, либо вспоминаю что мой дистрибутив ни разу не бинарный и делаю abs testing/название_программы и ставлю из исходников.

После апдейта стало: pr_a-2, pr_b-2, lib-2. Но pr_a-2 не работает с lib-2 по некоторым причинам. Хочется чтобы было pr_b-2 и pr_a-* (любой). Как это сделать?

Перекомпилировать pr_a-2. Либо поискать в AUR lib-1.

Ну и обновление всегда можно откатить.

> 1. apt-get install -t testing some_program

ну и как стейбл обновлять после такого?)

http://www.linux.org.ru/jump-message.jsp?msgid=4920341&cid=4920515 - вот товарищ дело советует

Никто не запрещает ставить одновременно несколько версий билиотеки, при условии что они не конфликтуют по именам файлов внутри [/usr]/lib[64], то есть вполне можно иметь libpng.so.0, libpng.so.1 и libpng.so.2 в один момент времени. Более того, в федорах и редхатах есть специальные пакеты compat-библиотек, содержащие старые версии libnss, libbdb, libstdc++, libX11 и других.

OpenSUSE.

1. Переключить основной источник пакета. (в yast 1 клик)
2. Обычно если программы из более-менее приличных репозиториев, это разруливают мейнтейнеры и мне нужно просто поставить пакеты. Если нет, можно собрать из сырцов нужные версии библиотек и программ с разными префиксами, возможно есть еще варианты, я не специалист в этих вопросах.

1. urpmi --media media1,...,mediaN package
2. Не бывает такого, ибо разруливается мантейнерами.

Дополнение по 2 - если действительно нужно иметь две и более версий, то делают compat пакеты

т.е. поставить то, чего нет на этих фтп-серверах или в портах не реально? я правильно понял? :)

В арче:

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

2. compat-пакеты. обычно нужны только для закрытых программ и как правило лежат в ауре.