At 12:47 PM 2/24/2004, Hamilton Andrew wrote: >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... Indeed, up2date is designed to service the 'end user'. And it's a great tool for those new to Linux. However, I live on the other side of the fence, doing research, development and supporting production machines. I provide the resolution to 'end user' issues, effectively shielding RedHat. Sometimes the most current version/RPM for a piece of software is the problem, not the solution. Trying to force qualified technicians to use a brain-damaged end-user interface is evil. RedHat needs to provide a support model for support personnel. This could be done by providing a means of access separate from up2date. That's my preferred solution, avoid the proprietary interface all together. Or perhaps, by yet more modifications to up2date. Yucky, but doable. For instance: a few new command line switched should do the trick. Something like: up2date --give-me-every-rpm-that-exists --channel rhel-i386-es-3 -d And: up2date --give-me-this-exact-rpm kernel-hugemem-2.4.21-4.0.2.EL.i686 -d Additionally, one should be able to run this from a non-RedHat supported machine. -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
