On Wed, 12 Mar 2003, Tom Diehl wrote: > > Is this so you could put $ARCH and $RHLVER in the config file and have > > it get them from the environment? > > ie: redhat-release, yellowdog-release, asplinux-release, etc > > That way it wouldn't be binding to only red hat's ver number. > I am thinking a good use of this is so that we could get the RHL ver from > rpm and use that to determine which repository to use. Is this what you > are suggesting above. yep -- I want to get the intelligence needed to correctly describe what a Client needs to solve dependencies, and the meta-dependency of which archive to use, wholly defaulted into the Client, with the help of a smart CGI Server side helping as a partner in the maintenance process. That means it has to be in the environment, in RPM, and in YUM, _on the Client_ One of the few downsides I currently see with yum > is that if I upgrade the distro I have to reconfigure yum. I have used > other updaters that handle that for me by using the info in rpm and > that way the upgrade is transparent to yum. If you can make that somehow > distro independent that would be a "Good Thing" (tm) I think. You understand part of the RFE's motivation. I sell the service of maintenance, and back porting, and have done so for years, long before up2date and such. Sometimes clients lose interest, or get a change in IS directors who view maintenance as a waste of money. Then their support contract runs out, and they get away from my maintenance constellation, and auto-repointed to the public (crowded) public mirrors. > When I say the info in rpm I am talking about the following: > redhat-release-8.0-8 Analogues exist for the other distributions, with varying consistency. That was a reason for doing a env variable passthru if present, to permit solving this kind of problem for not-yet supported in YUM variants. > Does this make sense or am I missing something?? Yep, it makes sense. Yep, it is deeper than that. -- Russ Herrold
