FS#5885 - couldn't pacman distribute mirror lists?

Attached to Project: Pacman
Opened by Moo-Crumpus (Moo-Crumpus) - Friday, 24 November 2006, 17:44 GMT
Last edited by Allan McRae (Allan) - Thursday, 24 July 2008, 06:27 GMT
Task Type Feature Request
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Low
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

couldn't pacman distribute mirror lists during updating?

- first step: fetch new mirror list.
- second step: update now.

Furthermore, if pacman.conf could include an option the way like:

REGION=EUROPE

pacman could prefer to adress mirrors in europe.

Just an idea.
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 24 July 2008, 06:27 GMT
Reason for closing:  Won't implement
Comment by Roman Kyrylych (Romashka) - Friday, 24 November 2006, 19:24 GMT
Well, it's a good idea, but if user changes mirror order in /etc/pacman.d/* then after upgrade these changes will be overwritten.
However, if pacman will be able to do round-robin rotation through all mirrors in [<your region>] section then it will not have big impact, I suppose ()providing that all mirrors are more/less equal).
The qestion is - how many users do change mirrors order? If many, then this feature is not very useful for them, if not many, then I think autoupdating mirror lists + round-robin rotation will be good feature to have.
Comment by John (Acid7711) - Friday, 02 February 2007, 19:22 GMT
I agree. With the amount of users flooooooding the main server, new commers won't know about mirroring. We need an automated tool that works and doesn't destroy settings, unlike some other nameless tools :D




However, what you're talking about it a static mirrored list I believe. We need something more that randomizes a good known mirror list and chooses appropriately. This is what took part on Gentoo and it handled large connections verrrrrrry well. A random server every sync or something similar would be an awesome, and also easy, way to stop these overrun servers. It would also stop people from asking why they're getting pacman errors all the time.

Saying "We hope users will sort their own mirrors" isn't working since there are numerous problems that people talk about all the time since they don't know why the error is occurring. Heck! Even a better error message saying "Too many connections to host, try again later" would be better than the given error messages now.

Comment by Roman Kyrylych (Romashka) - Friday, 02 February 2007, 19:30 GMT
Random mirror pool is bad when mirrors are highly non-equal in stability, fresheness, bandwidth and local/foreign traffic cost.
Connecting to closest local mirror would be better.
Better solution would be to ask user to run sortmirrors script during installation if connection is available, and output a message suggesting to run sortmirrors manually as soon as connection is established.
Anyway every new version of pacman package comes with updated mirrorlist.
Comment by Aaron Griffin (phrakture) - Friday, 02 February 2007, 19:35 GMT
Most of the ideas here are rather silly. "An automated tool" to change configurations files is strictly against the Arch philosophy.

That is not to say that pacman can't be more intelligent about what mirrors it uses (somehow selected the best / closest without slowing the process down). However, that doesn't imply some auto-selecting auto-updating list of mirrors pumped through some arch-based "debconf".

To solve the flood of users to ftp.archlinux.org, we just make sure we move that mirror down.

Comment by Roman Kyrylych (Romashka) - Friday, 02 February 2007, 19:43 GMT
Just wanted to correct my previous message, so you don't get me wrong - we can choose few good mirrors for round-robin scheme, of course.
Though, the more I'm thinking about this - the more I like current scheme + sortmirrors.
Comment by Moo-Crumpus (Moo-Crumpus) - Saturday, 03 February 2007, 09:15 GMT
Crud. My idea has nothing in common with debconf, and is neither silly nor strict against the kiss lemma.

Take a look what parts of pacman mirror configurations we really have so far:

/etc/pacman.conf
-- we list repositories here
-- the file itself advices users to add their own most wanted servers here!
== users can add their prefered servers here

/etc/pacman.d/...
-- lists of mirrors, installed with pacman that already HAS BEEN updated lately by pacman
-- latest version including a geographic separation (Europe), (Asia) ...

There is just one part of my idea left: if pacman.conf could include REGION=EUROPE, it was fine. Why?

Well, pacman.d mirror lists already are sorted in regions. I add my prefered servers in pacman.conf, as adviced. But if my prefered mirrors are not available, and pacman switches to pacman.d mirrors, it starts with asian servers. With a region flag pacman would know to start in the adressed region first.
Don't tell me it is against kiss, it isn't.

Comment by Roman Kyrylych (Romashka) - Saturday, 03 February 2007, 10:55 GMT
This exlanation is much better than original.
Comment by Allan McRae (Allan) - Thursday, 24 July 2008, 06:27 GMT
I think this can be handled by ordering and commenting out mirrors in the mirrorlist file. Otherwise this verges on being to Arch specific which we try to aviod in pacman.

Loading...