Нет Provides/Obsoletes libmtp8/libmtp8-devel, из-за чего проблематично обновиться с бэкпорченой программы, собранной для 4.1/branch с libmtp8
Я бы сделал необходимые зависимости в libmtp8, но это невозможно
М-м-м... Я собирал, видимо, по устаревшим правилам. Читаю, просветляюсь :-), твой спек в том числе. Не въехал сначала, почему libmtp8.
(In reply to comment #2) > Я собирал, видимо, по устаревшим правилам. Не, просто вперед паравоза никто не бежит обычно. Я amarok-2.0 себе собрал для 4.1, но класть в бранч или себе в репозиторий libmtp-0.3 не хочется, чтоб не поломалось ничего. Такая проблема у почти любого пакета может приключиться. > Читаю, просветляюсь :-), твой спек в том числе. Нет смысла. > Не въехал сначала, почему libmtp8. libmtp.so.8, потомо же, почему и libmtp5
Created attachment 3159 [details] спек-файл
Я, пожалуй, сделаю так: переименую бинарный пакет в libmtp8, devel оставлю как есть, добавлю Provides: libmtp = %version-%release. Obsoletes в этом случае тут не нужен, как я понимаю, пакет будет вытащен по предоставляемому libmtp.so.8. Это вроде как соответствует http://www.altlinux.org/Drafts/SharedLibs И для бэкпортежа достаточно релиз убавить. Да, в имена файлов с правилами я добавил %soversion, для исключения файловых конфликтов с 0.2.6.1. Если не будет возражений, вечером отправлю, счас спать надо, а проверить лучше на свежую голову. :-)
(In reply to comment #5) > Я, пожалуй, сделаю так: переименую бинарный пакет в libmtp8, devel оставлю > как есть, добавлю Provides: libmtp = %version-%release. Ок. Я в poppler так делаю.
0.3.4-alt2, вместе с 0.2.6.1-alt5 уехали в инкоминг. Я думаю, что все будет в норме.
Ок. Если у новой библиотеки с новым soname новое имя пакета всегда делать, то обновление без проблем происходит