It isn't Red Hat, per se, that you would need to convince, but the folks at rpm.org. The development of rpm was turned over to them some time ago. Not to say that Red Hat doesn't have any representation in rpm.org, but it's not solely their package any more.
I imagine the reply get may be something along the lines of "We'll be happy to look at any patches you submit." :) Mark Post -----Original Message----- From: Wolfe, Gordon W [mailto:[EMAIL PROTECTED]] Sent: Friday, February 07, 2003 12:47 PM To: [EMAIL PROTECTED] Subject: Re: RPM Data Bases and Sharing Linux Disks This is a magnificent idea. I started having trouble with the multiple rpm database situation about a year ago and posted it to this list. Looks like the situation hasn't changed much since then. If we could just have rpm search one shared global rpm database and one local rpm database (with all local updates being added to the local database and the global database being the local database for the master server), that would solve all my problems. The only problem I can see is getting Red Hat to create and implement the new standard. rpm does, after all, stand for "RedHat Package Manaager". They say there are three signs of stress in your life. You eat too much junk food, you drive too fast and you veg out in front of the TV. Who are they kidding? That sounds like a perfect day to me! Gordon Wolfe, Ph.D. (425)865-5940 VM & Linux Servers and Storage, The Boeing Company > ---------- > From: Scully, William > Reply To: Linux on 390 Port > Sent: Friday, February 7, 2003 6:34 AM > To: [EMAIL PROTECTED] > Subject: Re: RPM Data Bases and Sharing Linux Disks > > Richard, > > Valuable information, thank you! I'm going to discuss this further, if you don't mind. After all, a main selling point of Linux on the mainframe is leveraging the time and skill of our administrators. If we don't find ways of sharing packages we install among members of the Linux farm then we're not likely to make as much progress in this area as we could! > > > Imagine how nice it would be if RPM had a "hierarchy of data bases" in which it searched for prerequisites and co-requisites. When creating large farms of servers the so-called "master RPM data base" would have all the information about all the distributor-supplied packages which were installed on the system, plus any security patches which were recently applied. Then each individual server in the farm, which used the master server's disks in R/O, would be able to see that: > > - a package was installed already. That's good, no need to waste disk space reinstalling. > - a package was serviced. That's good, all the needed security patches are installed too! > > This is a big selling point for running Linux on mainframes! Do the work once and leverage it over and over again. > > However, each server in the farm has unique needs. So each user (owner) will want to install add-ons as needed. RPM would, in my scheme, keep a second data base updated (let's call it the "user's RPM data base"). Because RPM searches the master DB first and the user DB second, the tool still knows what's installed and most importantly, when things are refreshed. Certainly I could have given each server a copy of the original RPM data base, but over time that get's "stale", as it doesn't know about any patches recently installed. > > I can imagine that there could be times that installing a new level of (for example) Apache might imply that other packages have to be updated, in lock-step. (IE: when Apache isn't backward compatible. Perhaps an unlikely example, but let's go with it.) And that could mean that me, as owner of the master RPM data base and R/O disks need to take special effort to help my users prepare for upgrades. I think that could be handled. > > Does this sound like a helpful idea? > > -----Original Message----- > From: Richard Hitt [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 06, 2003 5:15 PM > To: [EMAIL PROTECTED] > Subject: Re: RPM Data Bases and Sharing Linux Disks > > > Hi, William > > The rpm database is nominally in /var/lib/rpm, if I'm not mistaken. An > unprivileged user should trivially be able to change this to his own > directory, by making a ~/.rpmmacros file and adding to it a %_dbpath > value. See /usr/lib/rpm/macros, in which you'll find: > %_dbpath ${_var}/lib/rpm > > That said, I don't at all see that the two rpm databases (the system's> > and an unprivileged user's) could possibly share information, but at > least now you know where rpm configuration parameters reside and how you > can override them. > > Richard Hitt [EMAIL PROTECTED] > > > Scully, William wrote: > > >I apologize for the long note. But this topic may be of particular interest to those of you hoping to create vast "farms" of Linux servers. And of particular interest if you hope to manage the software on these farms effectively. > > > >I've been reviewing the excellent document Linux on IBM eServer zSeries and S/390: Large Scale Linux Deployment, SG24-6824-00, in the hopes of using some of the techniques described there to create a farm of servers which share the maximum amount of directories in R/O mode. One objective is to allow an owner of a Linux server to install a package, using RPM, on their own server. Perhaps a copy of our locally-developed software; perhaps something the user needs or wants that they found on the Internet. Another objective is to be able to have me (or one of my peers) install security fixes or upgrade packages once, and see those updates on all the other servers. > > > >It seems in order to update a package that I'll need to keep strict R/W control over the RPM data base. After all that's how I know what's installed and what's been patched. But if an end-user wants to install a package, they too will need to interrogate and update the RPM data base. As I understand it there's only one RPM data base. > > > >This seems to be hard to solve. The authors of the Red Book mentioned above suggests that SPEC files can be used to force (ask?) that a separate RPM data base be used. That is, there would be one RPM data base for my work and another RPM data base for whatever the user did. However this presumes that whomever is installing the package knows (probably) a lot more about the nuances of RPM than may be practical, in real life. > > > >What might make this easier to handle is the ability, somehow, to merge two RPM data bases. Then, as I perform service on or added packages to the "base" Linux system, I would somehow "refresh" each user's copy of the RPM data base with what's current from mine. (Let's gloss over some obvious gotcha's about this, like what if the user installed THE first, then I installed it; who's entry to keep?) Does anyone know if this is possible (the merging of data bases)? > > > >Any other techniques you've found to be helpful would be appreciated, if you'd mention them here. > > > >William P. Scully > >Systems Programmer > >Computer Associates International, Inc > >2291 Wood Oak Drive > >Unit 5-29C > >Herndon, Virginia 20171 > > > >Work: +1 703 708 3976 > > > >[EMAIL PROTECTED] > > > > > > > > > >
