I agree. It is insufficient to most but the barest needs, but I think that is the way it was designed. RH only wants the current version of the RPMs available via this utility. I do understand the reasoning I guess, they save bandwidth and it's probably easier to say that they don't support past versions of RPMs and if you have issues with it then you should upgrade, blah, blah, blah, you know what I mean. It would be a nightmare to have to support various applications and all their previous versions and I'm not sure their structure supports even making them available. I would think that making them available might make support tougher because someone may accidently get old versions of stuff and on and on...
From: Bob Gorman [mailto:bob rsi com]
Sent: Tuesday, February 24, 2004 12:36 PM
To: redhat-list redhat com
Subject: RE: How to get RPMs without up2date?
At 01:33 PM 2/20/2004, Hamilton Andrew wrote:
>This solution may or may not work for you depending on what you want to do, but it may give you some other ideas. I do something like this because I have servers that don't ever connect to the internet and they have to updated as well.
>I have up2date configured to save the rpms after the install, I do an up2date -u via a cronjob, which works just fine. I then have the job move the newly installed rpms into a repository that is then transferred into my interior nework. I then have jobs that update my interior hosts, and I never lift a finger. You might get some use out of that and you might not or as they say "your mileage may vary...".
Yes, that's more or less what I do now. Except I used wget instead of up2date. The real questions is: How do we get RPMs without the use of up2date?
Why do this? Because up2date is a functionally delinquent application. It is incomplete and inefficient.
One can not download past or specific RPMs, or event all RPMs, for/from a given channel.
redhat-list mailing list
unsubscribe mailto:redhat-list-request redhat com?subject=unsubscribe