On Sat, Sep 20, 2008 at 01:37:59PM -0400, Jeff Johnson wrote:
> 	There's the additional wrinkle of handling
> 		Provides: /path/to/file
> 	which muddles the implementation further, because 2 indices need to  
> be searched.
> 
> 	Personally, I think its way past time to prohibit file paths in the  
> Providename index. A second source
> 	for paths adds a huge amount of complexity to all application  
> accesses, not just rpm, of an rpmdb for
> 	very little benefit other than that packagers and vendors get to  
> pretend that file paths in the Providename
> 	index is some sort of cool and useful feature.

In ALT Linux, "file-level" dependencies are essential.  I.e. when
a file path is known in advance, we use dependency on that path (e.g.
"Requires: /bin/sh").  And we have some complicated logic to translate
file-level dependencies with intermediate symlinks in path components,
e.g. /etc/init.d/functions -> /etc/rc.d/init.d/functions.

Now, some paths are are "virtual", which is e.g. executable paths under
update-alternatives(1) control.  Those paths are not packaged (and hence
cannot be accessed via Basenames index), but rather created in %post script.
We have find-provides hook which automatically provides virtual paths
(e.g. "Provides: /usr/bin/xvt" for xterm, rxvt-unicode etc.)

Other packages might want to require /usr/bin/xvt, which they actually
do require.  So, due to "virtual paths", file-like Provides cannot
be prohibited.

> 	From an engineering POV, paths in the Providename index just doubles 
> the amount of work needed
> 	to ensure whether a path is present (or not).

Most of the time, Basenames index lookup will do (since most paths are
non-virtual).  The amount of work gets doubled only when Providename
fallback is invoked.