1. We already leverage rsync. It will just be some setup on our end.
We should set it up on a different hostname and port. rsync://abs.archlinux.org:874 comes to mind. This will allow us to run a separate rsync service where we can force compression,etc on or off as we see fit.
I believe we can do so on a per stanza basis, so if we set a target for abs, then we can set options inside that stanza. It will take a bit of reworking of the existing config file maybe, but I don't think it will be overly problematic. I would like to avoid using alternate ports for this kind of stuff. For services that are for public consumption, it is good to use standard ports..so that it is more conformant to firewalling, etc.
3. It should migrate well. End users will just get the new abs package, and sync. There should be no need to nuke and refetch abs..just update with rsync.
Right. But do we use --delete in the abs client?
I would think so. We would just want to make sure to set a client side exclude option for /var/abs/local/
6. Standard from the end user perspective. Lots of similar things use rsync. I think bsd ports can be rsync fetched, for instance.
Good to know. Can you confirm this?
I can't seem to find a reference for my anecdotal statement. I didn't search very hard though. I thought I ran across it at one point, but who knows which BSD it was... maybe netbsd... *head scratching*