On Fri, 12 Mar 2004, Jeff Johnson wrote: > On Fri, Mar 12, 2004 at 01:05:26PM -0700, John VanSciver wrote: > > > > > > > > > > Is there anyway to have query and install/update functions search multiple > > RPM databases? I need to be able to have install update one database, but > > search 2 databases for dependencies. > > > > There is an old bugzilla request #4137 that describes exactly what I need, > > but I see no resolution done for the request. > > > > Heh, bug known well. > > After *years* of effort, I've managed to get a 2nd rpmdb opened by rpm and > searched if dependency is not found in /var/lib/rpm. > > This is the "Suggested resolution:" mechanism that is in the, > say, rpmdb-fedora package. > > The generalization to a full blown PATH-like list of databases > expressed conceptually as, say, > RPMDBPATH=/var/lib/rpm:/usr/lib/rpmdb/i386-redhat-linux/redhat:... > with the first database opened O_RDWR, with the others O_RDONLY used > to provide fifo suggestions for depsolvers seems to be a reasonable > approach imho. > I really like that aproach Jeff. Here is an example of where I might use multiple DB's. Right now we use relocatable rpm's to deliver content to our upgrade media (for instance the upgrade scripts, and then app developers can deliver add on's and config stuff). Right now I ignore the depedendencies when installing these relocatable packages, because most of them will be satisfied by system on which I am doing the upgrade, but not all of them. If I could check dependencies across the target systems db (I know what it should look like...similar to rpmdb-redhat thing), and the one I generate for the packages delivered to the media, then I could halt builds that looked like they may not work. Also, I could do the same sort of join if you will at install time, to determine that a system was missing stuff that my install scripts need. This is of course an over generalization, but perhaps it gives a "real" example of where such a feature might be used. > Instead, current depsolvers are exploring multiple repositories of headers > (or xml representations of headers). > > Similar conceptually, but lacking the speed of bsearch/hash on info retrieve. > > A path for rpmdb's is still in my rpm goal set, I'll get there yet. > Nice to know it is. I have other priorities ATM, but its one of those peripheral ones. Cheers...james > 73 de Jeff > > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
