FindPackage() should prefer virtual dependencies as they provide more semantics. E.g. /usr/bin/perl dependency exposes that perl interpeter is in use, while dependency on perl-base is not that meaningful. I think it's easy implement reverse lookup against rpm database: $ rpm -q --whatprovides /usr/bin/perl perl-base-5.8.7-alt2 perl-base-5.8.7-alt2 $ rpm -q --provides perl-base-5.8.7-alt2 |grep /usr/bin/perl /usr/bin/perl $ But there's a problem with reverse lookup using contents_index: $ awk '"/usr/bin/perl"==$1' ~sisyphus/i586/base/contents_index /usr/bin/perl perl-base $ Maybe we should alter how contents_index is generated so that it has both /usr/bin/perl perl-base /usr/bin/perl /usr/bin/perl Steps to Reproduce: $ rpm -q --whatprovides /usr/bin/perl perl-base-5.8.7-alt2 perl-base-5.8.7-alt2 $ RPM_BUILD_ROOT=/tmp . /usr/lib/rpm/find-package && RPM_BUILD_ROOT=/tmp FindPackage /tmp/script /usr/bin/perl Actual Results: perl-base Expected Results: /usr/bin/perl
The contents_index was defined to have one primary index - pathname (first field). Is it OK to leave only "/usr/bin/perl /usr/bin/perl" line there?
Anyway, when virtual dependence is provided by more than one alternative, it will remain virtual.
This could be implemented by extending contents_index format. But do we need this feature at all? I'm doubt.
Тема выбора между виртуальными и реальными зависимостями довольно тонкая. В общем, find-package недавно был переделан, и некоторый класс смежных/похожих проблем там был обдуман/решён. Возвращаться к этой теме я в ближайшее время не собираюсь, поэтому пусть будет LATER. А вообще надо переделывать contents_index подход потому что он не учитывает симлинков в путях. Но симлинки в путях учитывать вообще не так-то просто.
