FS#25028 - [pacman] Remove pacman-mirrorlist as dependency?

Attached to Project: Arch Linux
Opened by David J. Haines (dhaines) - Tuesday, 05 July 2011, 14:43 GMT
Last edited by Dan McGee (toofishes) - Tuesday, 05 July 2011, 16:54 GMT
Task Type Feature Request
Category Packages: Core
Status Closed
Assigned To Dan McGee (toofishes)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I was wondering whether it would be perhaps closer to KISS and/or more logically coherent not to have pacman-mirrorlist as a dependency of pacman. You don't actually need the mirrors to use pacman, and if you maintain a local mirror or build your own packages with ABS, /etc/pacman.d/mirrorlist just gets in the way and/or becomes cruft.

The only difference that I can see in practice would be that the user ends up either installing pacman-mirrorlist manually or (as is probably better in any event) uses the mirrorlist updater (http://www.archlinux.org/mirrorlist/) to make his/her own.

As another positive: doing this would allow the user to (cleanly) uninstall the pacman-mirrorlist and not have it updating itself periodically, thus getting rid of the requirement of handling the .pacnew file assuredly created.
This task depends upon

Closed by  Dan McGee (toofishes)
Tuesday, 05 July 2011, 16:54 GMT
Reason for closing:  Won't implement
Comment by Dan McGee (toofishes) - Tuesday, 05 July 2011, 16:52 GMT
As discussed on the pacman mailing list a bit, this is more of a hassle due to support issues than it is worth, as we aren't talking a heavyweight package here. Use a different filename than /etc/pacman.d/mirrorlist if necessary, Include declarations work on any file.
Comment by Dan McGee (toofishes) - Tuesday, 05 July 2011, 16:54 GMT
I should add this- adding a script to the pacman-mirrorlist package ala reflector that updates from the mirrorlist update site would be a welcome addition, if you are interested in tackling that particular bit of this request. Ideally it would depend on [core] packages only, lending itself to being written in bash or perl.

Loading...