[devel] robot friendship [was: eclipse-platform-3.3.0-alt5_30jpp5.0 -- file deps]

[Igor Vlasenko]

On Mon, Jan 21, 2008 at 12:54:28AM +0300, Alexey Tourbin wrote:

> > +eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	/usr/share/java/lucene.jar
> > -eclipse-platform-3.3.0-alt5_30jpp5.0	Requires	lucene
> У пакета 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 репозитариев.

Прошу прощения за задержку с ответом, был крайне перегружен :(

Напрашивается вариант #3.
пока нет ясности с 1) и 2), 
генерировать зависимости,
1) в случае, если согласно content_index_all такого файла нет
(вешать unmet)
2) файл есть и единственен (разрешать в зависимость на пакет)

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

Все равно apt ее не сможет разрешить. Зачем ее вообще ставить?
это же вредительство.

И робот станет другом человека :)

-- 

Dr. Igor Vlasenko
--------------------
Topology Department
Institute of Math
Kiev, Ukraine