Bug 7410 - find-package loses virtual dependencies
: find-package loses virtual dependencies
: Sisyphus
(All bugs in Sisyphus/rpm-build)
: unstable
: all Linux
: P2 normal
Assigned To:
: 2603
  Show dependency tree
Reported: 2005-07-20 20:08 by
Modified: 2008-02-26 00:20 (History)



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

Description From 2005-07-20 20:08:54
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
$ rpm -q --provides perl-base-5.8.7-alt2 |grep /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
$ RPM_BUILD_ROOT=/tmp . /usr/lib/rpm/find-package && RPM_BUILD_ROOT=/tmp
FindPackage /tmp/script /usr/bin/perl
Actual Results:  

Expected Results:  
------- Comment #1 From 2005-09-05 00:14:04 -------
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?
------- Comment #2 From 2005-10-07 18:49:02 -------
Anyway, when virtual dependence is provided by more than one alternative, it
will remain virtual.
------- Comment #3 From 2006-01-10 02:36:24 -------
This could be implemented by extending contents_index format.
But do we need this feature at all?  I'm doubt.
------- Comment #4 From 2007-11-10 00:50:08 -------
Тема выбора между виртуальными и реальными зависимостями довольно тонкая.
В общем, find-package недавно был переделан, и некоторый класс смежных/похожих
проблем там был обдуман/решён.  Возвращаться к этой теме я в ближайшее время не
собираюсь, поэтому пусть будет LATER.  А вообще надо переделывать
 подход потому что он не учитывает симлинков в путях.  Но симлинки в путях
учитывать вообще не так-то просто.