On Wed, Oct 08, 2003 at 06:40:52PM -0400, Jeremy Katz alleged: > On Tue, 2003-10-07 at 17:28, Christopher C. Weis wrote: > > 2) The ability to download, but not install, RPMs, using Yum. > > To throw my $0.02 out there for the heck of it. > > I think this is an option that has very little use. FTP clients, web > browsers, and mirroring programs all exist for a reason. I have yet to > see a convincingly good reason as to why a package updater should > replicate this functionality. > > I've heard a few reasons, and all of them seem ... questionable, at > least to me. Here's the sample of the ones I remember: > 1) "I want to evaluate the package before I install it" -- I fail to see > how having a binary package can help with that. Downloading the src.rpm > and diffing the contents, sure. But not the binary RPM. Changelogs > don't nearly have the information you want here. > 2) "I want to test it on another box first" -- Why not use yum on the > other box and download it and test it there. > 3) "I don't trust the code which installs packages" -- Then stop using > it. > 4) "Other programs that update packages have it" -- Some of them have > also corrupted rpmdbs in the past, that doesn't mean it's a good idea ;) These are reasons to download rpms... no reasons why yum should do it. The reason why yum should do it because yum can pick the correct file, and knows exactly where it is located. ftp/web clients don't know this. Currently yum doesn't even report the full URL to a file. If I could query full URLs to packages (like 'urpmq --sources'), then I'd be content to copy/paste the URL to wget. But the only way right now is to look at your yum.conf (which could be dynamically served from a CGI), guess at which repo holds the package, fire up a general ftp/web browser, and look for your package. I'd like yum to report full URLs. Then downloading manually would be trivial. (if you ignore the possiblity of requiring authentication, configuring proxies, etc).
