Bug 14328 - symlinks.req should resolve subpackage interdependencies
: symlinks.req should resolve subpackage interdependencies
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P2 normal
Assigned To:
:
:
:
:
:
  Show dependency tree
 
Reported: 2008-02-05 19:18 by
Modified: 2008-02-07 19:29 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2008-02-05 19:18:33
$ rpmquery --requires -p jboss4-4.0.3.1-alt2_5jpp5.0.noarch.rpm | grep jboss4  
                            
...
/usr/share/java/jboss4/jboss-common.jar  
/usr/share/java/jboss4/jboss-jmx.jar  
/usr/share/java/jboss4/jboss-system.jar  
/usr/share/java/jboss4/log4j-boot.jar  
/usr/share/java/jboss4/namespace.jar 
соответствующие симлинки привели с прописыванию неразрешенных зависимостей.
хотя все эти файлы входят в подпакеты того же srpm и зависимости на них должны
разрешаться в зависимости на соответствующие подпакеты.
------- Comment #1 From 2008-02-05 19:28:31 -------
symlinks.req should resolve subpackage interdependencies -
reassigned to author
------- Comment #2 From 2008-02-05 21:00:43 -------
непонятно кому мешают новые зависимости; если файлы есть, то зависимости будут
разрешены.
------- Comment #3 From 2008-02-05 21:46:42 -------
хорошо, если так; 
но я уже сталкивался с зависимостями, которые удоволетворяются на уровне rpm,
но apt их не вытягивает...
впрочем, скоро проверю.
------- Comment #4 From 2008-02-06 00:28:07 -------
удоволетворен вместе с зависимостями :)
------- Comment #5 From 2008-02-06 00:28:21 -------
no problem
------- Comment #6 From 2008-02-07 15:06:35 -------
Оптимизация (удаление) излишних зависимостей между подпакетами является спорной
темой.  Некоторые зависимости между подпакетами кажутся привычными (напр. пакет
rpm требует librpm-4.0.4.so), так что их удаление противоречило бы имеющейся
интуиции.  Другие зависимости между подпакетами (напр. rpm-build может
требовать
/usr/lib/rpm/functions из rpm) кажутся менее привычными, так что есть искушение
думать, что при наличии жесткой связи между подпакетами (через Requires: %name
=
%version-%release) их можно было бы удалять.  Но алгоритмически трудно
выразить,
какие из дополнительных зависимостей между подпакетами привычные, а какие
непривычные.  К тому же, с учетом транзитивности жестких зависимостей,
реализация удаления может оказаться нетривиальной.  Поэтому я пока склонен
думать, что дополнительные зависимости между подпакетами являются не "лишними",
а "уточняющими".  В уточнении же нет ничего плохого.  Пусть мы более точно
узнаем, какие связи имеются между пакетами, даже если они заранее связаны между
собой жесткой зависимостью.

Что до файловых зависимостей без явного provides с противоположной стороны, то
это тоже интересная тема.  Одним словом, я постарался сделать так, чтобы
анметов
в связи с такого рода зависимостями никогда не возникало.
------- Comment #7 From 2008-02-07 19:29:38 -------
согласен. Я опасался, что зависимости на файлы могут оказаться unmets с точки
зрения apt.
в данном случае не оказались :)
а вообще часто приходится нарываться на pseudo-unmets.
даже письмо писал в devel@:
-----------------------------------------------------------------------
at@:
> К сожалению, сейчас нельзя явно генерировать файловые зависимости между
> произвольными пакетами, т.к. при формировании репозитария apt обрезает
> файловые листы, так что есл пакеты находятся в разных репозитариях, то
> будет так называемый cross-arch semi-unmet.
> 
> Решения тут может быть два:
> 1) отказаться от раздельных $arch и noarch репозитариев; или же
> 2) не обрезать файловые листы при формировании $arch/noarch репозитариев.

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

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

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

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

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