Bug 52183

Created attachment 28714 [details]
steps to reproduce

Adding
	%files
	%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.

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.


Andras

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.

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
libutil.so.1
libutil.so.1(GLIBC_2.0)
redhat71:~% echo /bin/sh | /usr/lib/rpm/find-provides
redhat71:~%

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.


Andras

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.

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.

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.

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.