Sandra Carney <scarney@xxxxxxxxxxxxxxx> on 07/28/2004 04:13:28 PM came back with: > On Thu, 29 Jul 2004 Fulko.Hew@xxxxxxxxx wrote: > > > Sandra Carney <scarney@xxxxxxxxxxxxxxx> on 07/28/2004 04:13:28 PM asked: > > > > > I have similar concerns. Here is our problem. We have packages that > > > we want to install packages on NFS-mounted partitions. If we install > > > in the usual way, the rpm database in /var/lib/rpm gets updated. > > > To make queries about this NFS-mounted package, you have to goto the > > > machine on which the install took place to do the query because > > > /var/lib/rpm is local. > > > > > > What would be nice is to have an rpm database on an NFS-mounted > > > partition and into which NFS installs would be reported. > > ... snip ... > > > > which is the same problem being discussed here. > > > > > > Now, I could go ahead and create the virtual package. > > > However, that information is alreay in the database > > > in /var/lib/rpm and if the OS changes, they are now > > > out of sync. > > > > > > So what I propose is perhaps to have a datbase search path > > > when it comes to dealing with these matters. Maybe we have > > > a site option that says this is the order in which you > > > search the databases to find if something is provided. > > > > > > How hard would this be? > > > > What I think you need to do is: > > 1/ make the NFS. > > 2/ Since the NFS installed apps are common to all machines, > > you could? copy the RPM database files from one of those machines > > into that NFS copy. > > 3/ Then when installing an RPM destined for the NFS, use the NFS database. > > > > This will work until you update something on the NFS copy that > > has a dependency on something you may have installed locally. > > Now your databases are inconsistent, and you sorta.. gotta.. start over > > again. > > > > The better answer is to have all of the machines use a common > > NFS'ed root disk with a single RPM database and then the NFS > > installed packages would just work. > > I went a little fast in my original message. I forgot to mention > that we had entertained just copying the database in /var/lib/rpm > over to the NFS-one but then there is the synchronization problem. > We also have a heterogeneous set of machines. We have clinical > machines and we have development machines and their respective > rpm databases are going to look different. We can do that as a > stopgap measure but I was looking for ideas for a longer term > solution. Then the only thing I can think of (which doesn't exist) is that RPM needs to be enhanced to deal with 'n' databases, (in hind sight, that would be your 'search path' idea) so it would search both the local _and_ the NFS databases to determine dependencies. Probably not too hard to do, given the source for rpm _is_ available but is it the architecturally right thing to do? The workaround is to build the NFS database with 'dummy' entries. As was suggested yesterday, (my Fedora 2 and perhaps other) distributions come with /usr/lib/rpm/bpkg-provides.sh that you can use to build a dummy RPM to populate your NFS database with the minimum (with a little bit of work). After that you can manually (if neccessary) add to that 'dummy' RPM any other things that may be required. Yes this propbably suffers from a maintenance problem in your case, but it'll probably work for that minumum case to start with. In other words... two choices: 'fix it' or 'fake it'. :-) _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
