Bug 52183 - dependency checking failure when providing (not containing) a file
Summary: dependency checking failure when providing (not containing) a file
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2001-08-21 14:52 UTC by andras.nagy
Modified: 2007-04-18 16:36 UTC (History)
0 users

Clone Of:
Last Closed: 2001-08-27 09:43:51 UTC

Attachments (Terms of Use)
steps to reproduce (1.67 KB, text/plain)
2001-08-21 14:53 UTC, andras.nagy
no flags Details

Description andras.nagy 2001-08-21 14:52:39 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.75C-CERN UNIX pcitose1 45 [en] (X11; U; Linux
2.2.19- i686)

Description of problem:
unable to deal with the following situation: a package providing (not
containing) one file, another package requiring this file and the user
wants to install them in one transaction.

Version-Release number of selected component (if applicable): 

How reproducible:

Steps to Reproduce:
see attachment

Actual Results:  see attachment

Expected Results:  see attachment

Additional info:

see attachment

Comment 1 andras.nagy 2001-08-21 14:53:46 UTC
Created attachment 28714 [details]
steps to reproduce

Comment 2 Jeff Johnson 2001-08-25 14:48:53 UTC
	%ghost /some/file
will add a file element, not a Provides: element. Dependency
tokens that begin with '/' are resolved through different
means than other dependencies.

Yes, the command
	rpm -q --whatprovides /some/file
"works", but that's a CLI choice, not a claim
that files and dependency tokens use the same
underlying implementation.

Comment 3 andras.nagy 2001-08-25 16:44:01 UTC
Two points.

First, what if they are resolved through different means?  The packages can be 
installed in two steps, therefore the dependencies ARE SATISFIED, regardless 
of "underlying implementation", and RPM fails to confirm this when doing the 
installation in one transaction.  What's this if not a bug?  Both methods for 
installation should either succeed or fail, consistently.  (Should it work this 
way according the current implementation does not mean it's not a bug.  ;-)

Second, the suggested workaround does not really do what I want.  The file must 
exist when building the package (error: File not found: /some/file) -- why 
if "a %ghost tag on a file indicates that this file is not to be included
in the package" ?  When installing the package, the file does not get created --
 fine.  Upon removal, RPM claims that the file does not exist, so I suppose it 
was about to remove it.  As you may have figured out, I am trying to build 
dummy packages which provide /bin/sh and similar things, in order to use RPM on 
platforms where the base system is not RPM-based.  So removing these files is 
not a good idea.  Anyway, all this is not really relevant to this bug report, 
so just focus on the first point please.


Comment 4 Jeff Johnson 2001-08-25 17:09:40 UTC
Actually the 2nd point may be more relevant. Have you looked at
/usr/lib/rpm/vpkg-provides*.sh? vpkg-provides2.sh is the better of
the two (but needs some tweaks). These packages try to automate
the generation of a spec file that, when built, describes an existing
native p[latform (like Solaris) that is not managed with rpm.

Comment 5 andras.nagy 2001-08-25 18:01:04 UTC
Yes, what I'm using to build packages is based on vpkg-provides2.sh.  However, 
as it is based on find-provides, it only generates `classic' provides fields, 
(not beginning with /) while it is common to rpm packages to have `file' 
requirements (beginning with /, most common being /bin/sh).  (BTW, all this 
file-based dependency stuff is quite a bad concept I think, but we have it so 
have to deal with it.)  For instance:

redhat71:~% echo /lib/libutil-2.2.2.so | /usr/lib/rpm/find-provides
redhat71:~% echo /bin/sh | /usr/lib/rpm/find-provides

For these reasons, I also include all the files the native system packages 
contain in the Provides: field of the dummy package.  (Thus it will get quite 
huge and takes hours to build, but again, this is not relevant. :-)

And when I want to install such a package which provides (for instance) /bin/sh 
and a package which requires /bin/sh in one transaction, it fails.

While this is a good example, actually this is not our main concern.  (We can 
install the dummy package first on it's own, and do the rest in transactions.)  
However, our packaging system is a little bit more complicated.

In short, we will need packages not containing actual files, but creating links 
into a central repository from postinst scripts (or containing a few links into 
this repository, some of them possibly pointing to directories, which contain 
additional files).  That is, the files are not in the package, but the package 
takes the necessary steps to provide them.  Therefore, we put the list of the 
provided files in the Provides: field.

And some other packages require these files.

And there are scenarios, when lot of packages are to be either upgraded, 
installed or removed, and they have complex dependencies on each other. And we 
want to ensure system consistency all the times.

Therefore, we want to do all these installations, upgrades and removals in one 
transaction.  (As the rpm CLI interface does not allow this, while rpmlib does, 
I have written a tool that uses rpmlib and allows installations and removals in 
one transaction.)

And then, we will surely face this bug.


Comment 6 Jeff Johnson 2001-08-25 18:20:26 UTC
Good, you're using vpkg-provides2.sh. Please send me patches for
anything that is not to your taste.

What's killing your approach is your perceived requirement
that the virtual package be included in the one single transaction.
If you install the virtual package before installing everything else,
then I believe that unsatsifiedDepend() in lib/depends.c will
be perfectly happy with a
	Provides: /bin/sh
What's missing is that, for incoming packages,  alSatisfiesDepend()
is used to check Provides: and file names, and does not, for example,
check the incoming Provides: list if a dependency token starting with '/'
is not found in the files list (just a guess, haven't looked hard). I'll
try to get this fixed, but not in rpm-4.0.3.

Meanwhile, using %ghost for links that are created in %post should
work fine (as best I understand your problem description).

So I'd try a two stage (i.e. two transaction) upgrade, with your own
all-or-nothing downgrade on failure for the virtual package. Otherwise,
try %ghost with symlinks cretaed in %post.

I also point out that there's only a handful of file dependencies, mostly
for interpreters like /bin/sh and /usr/bin/perl, that really need to be included
in the virtual package, almost all other dependencies can be, and in fact are,
even should be, expressed using other forms of dependencies.

Comment 7 Jeff Johnson 2001-08-25 18:26:25 UTC
Hmmm here's a (reversed, sigh) patch that might fix you up:

--- depends.c	Sat Aug 25 14:32:56 2001
+++ depends.c.new	Sat Aug 25 14:31:15 2001
@@ -1079,11 +1079,8 @@
     struct availablePackage * p, ** ret = NULL;
     int i, rc, found;
-    if (*keyName == '/') {
-	ret = alAllFileSatisfiesDepend(al, keyType, keyName);
-	if (ret)
-	    return ret;
-    }
+    if (*keyName == '/')
+	return alAllFileSatisfiesDepend(al, keyType, keyName);
     if (!al->index.size || al->index.index == NULL) return NULL;
Again, I can't add the patch to rpm-4.0.3, it's too late, but I'd be
interested in hearing if it solves your problem.

Comment 8 andras.nagy 2001-08-27 09:43:47 UTC
Fine, this seems to fix it.  At least, the example in the original bug report installs cleanly in one transaction now.  (And RPM still seems to detect real unsatisfied dependencies.)  Thanks.

As for vpkg-provides2.sh, I actually do not use it, nor patched it.  What I use is a Solaris-specific perl script building the dummy package for Solaris, and I said it's based on vpkg-provides2.sh because I got the idea of using pkgchk -l from there.

Comment 9 Jeff Johnson 2001-08-30 17:19:03 UTC
The patch should be in my next checkin, will be in rpm-4.0.3-1.02.

If your script is better than vpkg-provides2.sh , please open
a bug report a append a copy of the script, as I'd like to
improve automated virtual package building in the future.

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