provides и conflicts: что когда применять и каким образом

Как и ожидалось, уже через день после введения этих функций началась путаница. Здесь я попробую разъяснить, что в каких случаях надо применять, и как это делать правильно.

Не применяйте conflicts. На сегодняшний день существует всего один случай, когда его применение оправдано. Все остальные ситуации разрешимы через provides!

Всё остальное - уже мелочи.

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

К таким случаям относится:

• Одна и та же программа, собранная с различными патчами (например, fontconfig и fontconfig-cleartype)
• Одна и та же программа, собранная с различными взаимоисключающими опциями (например, QtCurve-KDE4 и QtCurve-Qt)
• Одна и та же программа, собранная в связке с разными библиотеками (например, MPlayer и MPlayer-vdpau)
• Разные программы, выполняющие одно и то же, при этом - взаимозаменяемые в качестве зависимостей (например, dcron и vixie-cron).

К таким случаям НЕ относится:

• Программы/либы, которые могут существовать в системе одновременно
• Программы, которые выполняют одно и то же, но не могут служить взаимозаменяемыми зависимостями для чего-либо (например, разные IM - psi, qutim).
• Программы, зависимые друг от друга.

1. Если возможно определить, какой из вариантов основной - то в качестве provides следует указывать именно его. Хороший пример такого случая - fontconfig: основной пакет - это fontconfig, а альтернативный вариант fontconfig-cleartype имеет запись provides freetype.
2. Если главный пакет определить невозможно, то в качестве записи для provides выбирается некоторая базовая часть имени этих пакетов. Хорошим примером служит dcron и vixie-cron: оба они предоставляют cron.¹⁾
3. Имя пакета должно содержать значение записи provides, т.е. если provides=blabla, то имя пакета должно содержать blabla, например blabla-foo. Сделано для предотвращения злоупотреблением provides, чтобы пакет fuck-1.0-noarch.txz не имел записи provides=kernel, а так же для анализа доступных альтернатив в инсталляторе.
4. Важно понимать, как должно выглядеть имя: $CORENAME-$ALT. Говоря простым языком, имя пакета должно начинаться с имени основного пакета, а далее уже через дефис добавляться альтернативы. Правильно: основной пакет google-chrome, альтернативный пакет google-chrome-iron у которого provides google-chrome. Неправильно: google-chrome и iron provides google-chrome.

Как я уже говорил выше, не применяйте это. Если вы считаете что у вас именно тот редкий случай, когда надо применить conflicts а не provides - подумайте еще раз, попробуйте еще раз реализовать схему через provides, и только в крайнем случае прибегайте к помощи conflicts.

Вообще говоря, применять conflicts надо тогда, когда по каким-то причинам два пакета объединились в один. Пример на данный момент лишь один: начиная с KDE 4.4, пакет kdelibs-experimental вошел в состав kdelibs. Поэтому в пакете kdelibs-4.4 будет указано: conflicts kdelibs-experimental.