[devel] eclipse-platform-3.3.0-alt5_30jpp5.0 -- file deps

[Alexey Tourbin]

>  eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	/usr/lib/eclipse/plugins/org.eclipse.swt.gtk.linux.x86_3.3.0.v3346.jar
> +eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	/usr/share/java/lucene-contrib/lucene-analyzers.jar
> +eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	/usr/share/java/lucene.jar
>  eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	ant
> @@ -23077,4 +23160,2 @@
>  eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	libgtk-x11-2.0.so.0
> -eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	lucene
> -eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	lucene-contrib
>  eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	mx4j >= 2.1

У пакета eclipse-* в очередной раз "плавают" зависимости.
Дело здесь в том, что разрешение файлового пути в зависимость
идёт через механизм contents_index_all.  Этот механизм по сути нужен
для того, чтобы разрешать файловые (виртуальные) зависимости в реальные
зависимости -- в тех случаях, когда такое разрешение однозначно.

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

Раньше файловая зависимость /usr/share/java/lucene.jar однозначно
разрешалась в пакет lucene.  Теперь в репозитарии есть два пакета --
lucene и lucene1, которые содержат этот файл, поэтому ничего не
остаётся, как только сохранить файловую зависимость as is.
Если же удалить из репозитария пакет lucene1, то опять "восстановится"
зависимость на lucene.

Это наводит меня на мысль, что, по идее, сам механизм contents_index_all
в общем-то не нужен.  Результат слишком сильно варьируется от текущего
состояния репозитария.  Если пакет явно требует какой-то файл, то пусть
он просто требует этот файл, а дополнительный шаг по поиску реального
пакета с этим файлом ничего хорошего не даёт, а только "не по делу"
преобразует зависимость (и, кстати, ослабляет гарантию по наличию
соответствующего файла в новых сборках пакета).

К сожалению, сейчас нельзя явно генерировать файловые зависимости между
произвольными пакетами, т.к. при формировании репозитария apt обрезает
файловые листы, так что есл пакеты находятся в разных репозитариях, то
будет так называемый cross-arch semi-unmet.

Решения тут может быть два:
1) отказаться от раздельных $arch и noarch репозитариев; или же
2) не обрезать файловые листы при формировании $arch/noarch репозитариев.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 197 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20080121/73a49e43/attachment-0002.bin>