On Mon 10 Mar 2003 08:00, François Pons posted as excerpted below: > This could be great indeed, any idea how to improve urpmi/rpmdrake is > welcome as next version will be designed soon now.
Something I've been wishing for.. If it's there, I haven't seen it in the man pages or documentation.. Some way to prioritize sources.. Thus, if my local mirror has the same thing as the sunet primary mirror, it wouldn't bother sunet, but would go for the local one, but would still be able to get the latest from sunet when there's a difference. A somewhat related request.. It doesn't LOOK like it's doing this now, but maybe it does.. If several sources are available for an item, according to the latest hdlst.cz, and one fails, try the others. I've had errors where it was gone from one, apparently the one urpmi tried first, but still available on another, only urpmi wouldn't fetch it from there. I either had to disable the first source, or go fetch it manually (which is how I knew it to be available on the second source anyway). Talking about disabling.. AFAIK, the only way to do that is thru the GUI interface. If there's a command line way to do it, I'd like to know it. I suppose I could create a script that renamed the files so urpmi skipped that, but I'd THINK there'd already be a way to do it, since the GUI can. Am I missing something? Also nice would be.. Some way to tell it "if app.x.y.z doesn't exist, automatically try app.x.y.z-Amdk doesn't exist, try -(A+1)mdk instead." IOW, it would do the same thing that urpmi already does to figure out which of several versions is the newest, but if the hdlist.cz file was outdated, it would automatically try the next logical release stepping instead, as well as the usual output about needing to run .update. It's a bit arguable as to whether it should extend beyond the mdk release number, say, to the .z above, but at least the mdk releases are usually fairly limited in scope, so having at least that as an option would be helpful. (The idea is an option like --allow-force, for those that want it, not default behavior, for those that prefer a more conservative approach.) And, possibly all in the documentation department.. More info on parallel would be useful. For instance, I have just a single computer, but a 3Mbps d/l cable modem connection. It's frustrating sitting there watching an overloaded server attempt to service my urpmi.update -a, at a mere 100KB/sec, when the connection can do 3 times that, and when I know there are several other servers to be updated after that. Could I somehow use parallel to initiate a second session and .update a second server at the same time? If so, instructions would be nice. If not, that ability would be very nice in the next version. Something tells me that's why parallel is there, altho one gets the impression that was designed to work on physically separate hosts. The existing man documentation is pretty good on detail, but it doesn't seem to say much about parallel. I've only the rather sparse changelog mentions to go on. -- Duncan "They that can give up essential liberty to obtain a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin
