Transition to disttag

В "идентификаторах" пакетов (основных Provides) появился disttag (D: N-E:V-R:D), который различает разные сборки пакета из одних и тех же исходников (E:V-R). Disttag имеет особую семантику при участии в удовлетворении зависимостей и т.п., а также при принятии решения об обновлении (какая сборка пакета будет предпочтительна).

Желаемое поведение

Желаемое поведение rpm ("rpm-install") в отношении disttag вот такое:

...

Мы полагаем, что такое поведение уже реализовано в "новом" rpm ("rpm-install"), а именно 4.13.0.1-alt5.

Особенности поведения "нового" и "старого" rpm ("rpm-install") в отношении disttag

Здесь нас особенно волнует поведение "старого" rpm ("rpm-install"), а именно 4.13.0.1-alt4 или старого из p8 и пр., при столкновении с пакетом, где уже используется disttag (был добавлен туда "новым" rpm-build).

Что касается "нового" rpm ("rpm-install"), то он задуман так, что требования N > E:V-R:D и N > E:V-R (без disttag) будут удволетворяться одним и тем же множеством пакетов (потому что disttag-и несравнимы), а значит, будут иметь одинаковый эффект:

• Requires: N > E:V-R:D и Requires: N > E:V-R (без disttag);
• Conflicts: N > E:V-R:D и Conflicts: N > E:V-R (без disttag);
• Obsoletes: N > E:V-R:D и Obsoletes: N > E:V-R (без disttag).

То же самое верно для другого строгого знака: требования N < E:V-R:D и N < E:V-R (без disttag) будут удволетворяться одним и тем же множеством пакетов.

Проверка Conflicts старым rpm

Проверка Conflicts: N > E:V-R (без disttag)

В качестве примера пакета с таким Conflicts возьмём wireshark, известный из bugzilla.altlinux.org:

curlftpfs -o allow_other,kernel_cache ftp://ftp.altlinux.org/pub/distributions/archive /home/user/MNT/ALT/repo