Что значит "устанавливал tramp новее, чем в дистрибутиве M24"? Откуда вы его взяли?
В Sisyphus последняя версия (перед выносом в orphaned) была 2.0.39-alt1, эта же
версия была в M24 и С30.

Прям из спека и взял. 2.0.39-alt1 там. В Сизиф только на этот счёт не заглянул.
Но заметил, что в M24 тоже версия. Это вроде совпадение.
Это я к своему use case:
поимев какие-то проблемы с удалённой работой с RCS в tramp я его обновил до
2.0.5x. Сейчас пришлось вручную удалять emacs-tramp перед установкой
emacs22-common (конфликт файлов из этих пакетов возникал, хотя между самини
пакетами конфликта нету). ИМХО, привязку к определённой версий в obsoletes надо
выкинуть, всё равно emacs-tramp лёг в orphaned.

И вообще, если уж tramp из сборки emacs22 не выделяется в отдельный пакет, то
имеет смысл ставить Conflicts: %shortname-tramp. Ведь какую версия ни ставь, всё
равно возникнет конфликт по спискам файлов. Пусть уж лучше будет конфликт пакетов. 

Это же касается и других "изкоробочных" компонентов emacs22. Тут вроде два
варианта: либо оставить как есть (и убрать указания на версий пакетов), либо
выделять (ряд) компонентов в отдельные пакеты. Второй путь выглядит
перспективнее, т.к. можно будет эти компоненты по частям штатно обновлять
(впрочем, непонятно, действительно ли это нужно). Но и геморойнее конечно.

То, что было сделано - было правильно.
Во первых, по поводу conflicts: он хорош, когда необходима установка одного из
взаимоисключающих пакетов. В данном случае по смыслу правильным будет именно
obsoletes - ведь emacs22-common содержит тот же emacs-tramp, только более свежей
версии.
Теперь - по поводу того, чтобы убрать версионирование obsoletes - рано или
поздно выйдет релиз emacs22, его развитие остановится и версия tramp, входящая в
его состав будет далее неизменна. А tramp будет развиваться дальше - это значит
однажды может возникнуть потребность вернуть emacs-tramp в Sisyphus. Текущая
схема позволяет это сделать без какого-либо изменения в emacs22.

Итого, я в данный момент вижу два варианта, как мне поступить с этой записью в
bugzilla:
1. Закрыть баг как INVALID - в конце концов за пакеты, которые вы собираете сами
отвечаете именно вы, а не майнтейнеры соседних пакетов.
2. Увеличить версию tramp в obsoletes, написать
Obsoletes: %shortname-tramp < %tramp_version-%release
и (возможно) выделить tramp в отдельный подпакет.

Хм. Вы правы, только сейчас дотумкал - втроенный трамп и внешний таки не будут
конфликтовать по списку файлов. Только с инициализацией разрулить.

> 1. Закрыть баг как INVALID - в конце концов за пакеты, которые вы собираете сами
отвечаете именно вы, а не майнтейнеры соседних пакетов.

Логично и справедливо, но лучше таки пункт 2.

> 2. Увеличить версию tramp в obsoletes, написать
Obsoletes: %shortname-tramp < %tramp_version-%release

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

> и (возможно) выделить tramp в отдельный подпакет.

Проблема шире - их, как обычно, "миллионы". Подпакетов в смысле. Разница между
"резать/не резать" только в том, будут ли лежать на винте файлы устаревшего
подпакета. Можно наверно и не резать. Токько инциализацию/загрузку подпакетов,
перекрывающих входящие в emacs надо сделать.

P.S.: Сейчас посмотрел внимательнее, что эти пакеты не поделили. Вы будете
смеяться: один файл (/usr/share/info/tramp.info.bz2). Почему-то вспомнились
alternatives, с которыми дома была затяжная войнушка :-)

Исправлено в 22.0.50-alt0.14.20060715