Duncan <[EMAIL PROTECTED]> writes: > 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.
The sources are taken in order. In 9.2 the sources editor will have the feature of graphically changing order. Now, you may do so by changing order of `/etc/urpmi/urpmi.cfg'. > 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). I think this is available (or soon will be) with urpmi. But this is gonna be hard for rpmdrake since the installer/downloader is grpmi, which doesn't know anything about dependencies (it only installs/downloads). > 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.) This wouldn't be safe since a new release may have different dependencies. -- Guillaume Cottenceau - http://people.mandrakesoft.com/~gc/
