So would I, but for what I've seen the SHA1 information is not part of the mirrormanager database. For any "good" implementation of metalinks in the mirrormanager, I would at least want trustworthy SHA1 information in the database otherwise the only advantage of using metalinks would be load balancing on your mirrors (which is already mostly fixed with MM). So for the end user, there is not much to gain if metalinks is implemented in the mirrormanager. The only solution for the SHA1 information I could think of was to implement a script on the main mirror which hosts the SHA1 files, which would mean not running on the server with the MM database, which would mean not having direct access to that database. Parsing HTML is pretty stupid, I agree, but there is probably a much cleaner way of getting the mirror list (I havn't worked with turbo gears before, so I couldn't find a view of the list I would want). Something like fedora-test-data/mirror-hosts-core.txt would be much better. Rene is still working on the MM patch, but without the SHA1 information, I'm not really sure it would be _my_ ideal solution. Greets, Bram On Mon, Mar 17, 2008 at 6:14 AM, Matt Domsch <Matt_Domsch@xxxxxxxx> wrote: > You don't want to spider this data all over again (the HTML pages are > really quite bare...) - you really want to get it from the MM database > directly. I'd much prefer to see efforts aimed in that direction, > than for a throwaway implementation that doesn't use the MM database. > > -Matt > -- > > Matt Domsch > Linux Technology Strategist, Dell Office of the CTO > linux.dell.com & www.dell.com/linux _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
