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
> 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.
Received on Mon Sep 22 08:44:47 2008
- application/pgp-signature attachment: stored