RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Two limitations of triggers in rpm

From: Jeff Johnson <n3npq@mac.com>
Date: Mon 22 Sep 2008 - 15:28:21 CEST
Message-id: <4A511FAB-C49A-4DA7-870E-1E834DF9F6F5@mac.com>

On Sep 22, 2008, at 9:06 AM, Alexey Tourbin wrote:

> On Mon, Sep 22, 2008 at 07:38:03AM -0400, Jeff Johnson wrote:
>>> 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.)
>>
>> So use a probe dependency like
>>     Requires: executable(/path/to/alternative)
>> The probe will be evaluated at run-time, and even permits rpm to
>> interoperate with dpkg alternatives.
>
> I don't need runtime probe at all, I need to resolve/install the
> dependency.
>
> # apt-get install /usr/bin/xvt
> Reading Package Lists... Done
> Building Dependency Tree... Done
> Package /usr/bin/xvt is a virtual package provided by:
>   xterm 237-alt1 [Installed]
>   termit 1.3.5-alt1
>   rxvt-unicode 9.02-alt1 [Installed]
>   kdebase-wm 3.5.10-alt4
>   kde4base-konsole 4.1.1-alt1
>   gnome-terminal 2.22.3-alt1
>   aterm 1.0.1-alt3 [Installed]
> You should explicitly select one to install.
> E: Package /usr/bin/xvt is a virtual package with multiple good  
> providers.
> #

We're talking at cross-purposes here ...

If you want to put
     Provides: /usr/bin/xvt
into packages as a means of representing update-alternatives, and
to be conformant with whatever is being done by apt-rpm, that's fine.

I'm talking about whether
    Provides: /usr/bin/xvt
(and any token starting with '/') should be added to the /var/lib/rpm/ 
Providename
table. Databases are useful iff the tables contain predictable  
content. Every usage
case of a dependency (in my case I'm trying to generalize trigger  
dependencies
to include paths) has to look in multiple locations "just in case"  
update-alternatives is
in use.

That's a whole lot of complexity introduced into rpmdb  
implementations. And then there's applications,
most of which do not look in Providenames after Basenames for tokens  
starting
with '/', so why should rpm itself bother?

You might just as well put your bank balance, or your current  
latitude & longitude,
just for some exotic examples of what is wrong with putting paths  
into the Providename
table.

Since there are like 300K+ file paths, and perhaps 50 update- 
alternative paths, I'm
questioning whether there is any gain in storing static paths into  
rpmdb tables.

update-alternatives is intrinsically a run-time operation, the  
symlink paths
can be easily altered, making the dependency meaningless, outside of
rpm.

73 de Jeff
Received on Mon Sep 22 15:28:46 2008
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.