$ 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 и зависимости на них должны разрешаться в зависимости на соответствующие подпакеты.
symlinks.req should resolve subpackage interdependencies - reassigned to author
непонятно кому мешают новые зависимости; если файлы есть, то зависимости будут разрешены.
хорошо, если так; но я уже сталкивался с зависимостями, которые удоволетворяются на уровне rpm, но apt их не вытягивает... впрочем, скоро проверю.
удоволетворен вместе с зависимостями :)
no problem
Оптимизация (удаление) излишних зависимостей между подпакетами является спорной темой. Некоторые зависимости между подпакетами кажутся привычными (напр. пакет rpm требует librpm-4.0.4.so), так что их удаление противоречило бы имеющейся интуиции. Другие зависимости между подпакетами (напр. rpm-build может требовать /usr/lib/rpm/functions из rpm) кажутся менее привычными, так что есть искушение думать, что при наличии жесткой связи между подпакетами (через Requires: %name = %version-%release) их можно было бы удалять. Но алгоритмически трудно выразить, какие из дополнительных зависимостей между подпакетами привычные, а какие непривычные. К тому же, с учетом транзитивности жестких зависимостей, реализация удаления может оказаться нетривиальной. Поэтому я пока склонен думать, что дополнительные зависимости между подпакетами являются не "лишними", а "уточняющими". В уточнении же нет ничего плохого. Пусть мы более точно узнаем, какие связи имеются между пакетами, даже если они заранее связаны между собой жесткой зависимостью. Что до файловых зависимостей без явного provides с противоположной стороны, то это тоже интересная тема. Одним словом, я постарался сделать так, чтобы анметов в связи с такого рода зависимостями никогда не возникало.
согласен. Я опасался, что зависимости на файлы могут оказаться 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 ее не сможет разрешить. Зачем ее вообще ставить? это же вредительство. И робот станет другом человека :)
