Bug 625922

So, this is not really a yum problem but mirror manager not returning valid metalink.  I think mirror manager could just redirect from updates repo to base repo. Copying mdomsch

Well there _is_ data it's just bad. For the above URL you currently get:

<?xml version="1.0" encoding="utf-8"?>
<!--
# repo = updates-released-f14 arch = x86_64 error: invalid repo or arch
# following repositories are available:
# repo=core-2, arch=i386
# repo=core-2, arch=x86_64
# repo=core-3, arch=i386
# repo=core-3, arch=x86_64
# repo=core-4, arch=i386
# repo=core-4, arch=ppc
# repo=core-4, arch=x86_64
[...]

# repo=updates-testing-source-f9.newkey, arch=source
# repo=updates-testing-source-fc6, arch=source

-->

...the problem is that isn't a valid XML document (no start tag). In theory if MM was changed to produce something like:


<?xml version="1.0" encoding="utf-8"?>
<metalink version="3.0" xmlns="http://www.metalinker.org/" type="dynamic" pubdate="Fri, 20 Aug 2010 20:22:32 GMT" generator="mirrormanager" xmlns:mm0="http://fedorahosted.org/mirrormanager">

<!--
# repo = updates-released-f14 arch = x86_64 error: invalid repo or arch
[...]

-->

</metalink>

...we could maybe do something. Or, as Rahul says, MM could just make updates == updates-testing or a blank repo. or something.

I added this patch to MM upstream (after 1.3.6 which is currently deployed).

commit aee20493d04f061e6b7733e808807326a455b076
Author: Matt Domsch <Matt_Domsch>
Date:   Mon Aug 23 10:48:02 2010 -0500

    mirrorlist_server: always output a metalink header

    reported in https://bugzilla.redhat.com/show_bug.cgi?id=625922

    the metalink failuredoc did not include the metalink header as would
    be required to be considered valid XML.

diff --git a/mirrorlist-server/mirrorlist_server.py b/mirrorlist-server/mirrorlist_server.py
index 9c85343..e366f33 100755
--- a/mirrorlist-server/mirrorlist_server.py
+++ b/mirrorlist-server/mirrorlist_server.py
@@ -91,15 +91,27 @@ def uniqueify(seq, idfun=None):
         result.append(item)
     return result

-
 ##### Metalink Support #####
-def metalink_failuredoc(message=None):
+
+def metalink_header():
+    # fixme add alternate format pubdate when specified
+    pubdate = datetime.datetime.utcnow().strftime("%a, %d %b %Y %H:%M:%S GMT")
     doc = ''
-    doc += '<?xml version="1.0" encoding="utf-8"?>\n'
+    doc += '<metalink version="3.0" xmlns="http://www.metalinker.org/"'
+    doc += ' type="dynamic"'
+    doc += ' pubdate="%s"' % pubdate
+    doc += ' generator="mirrormanager"'
+    doc += ' xmlns:mm0="http://fedorahosted.org/mirrormanager"'
+    doc += '>\n'
+    return doc
+
+def metalink_failuredoc(message=None):
+    doc = metalink_header()
     if message is not None:
         doc += '<!--\n'
         doc += message + '\n'
         doc += '-->\n'
+    doc += '</metalink>\n'
     return doc

 def metalink_file_not_found(directory, file):
@@ -108,8 +120,6 @@ def metalink_file_not_found(directory, file):

 def metalink(cache, directory, file, hosts_and_urls):
     preference = 100
-    # fixme add alternate format pubdate when specified
-    pubdate = datetime.datetime.utcnow().strftime("%a, %d %b %Y %H:%M:%S GMT")
     try:
         fdc = file_details_cache[directory]
         detailslist = fdc[file]
@@ -119,14 +129,7 @@ def metalink(cache, directory, file, hosts_and_urls):
     def indent(n):
         return ' ' * n * 2

-    doc = ''
-    doc += '<?xml version="1.0" encoding="utf-8"?>\n'
-    doc += '<metalink version="3.0" xmlns="http://www.metalinker.org/"'
-    doc += ' type="dynamic"'
-    doc += ' pubdate="%s"' % pubdate
-    doc += ' generator="mirrormanager"'
-    doc += ' xmlns:mm0="http://fedorahosted.org/mirrormanager"'
-    doc += '>\n'
+    doc = metalink_header()
     doc += indent(1) + '<files>\n'
     doc += indent(2) + '<file name="%s">\n' % (file)
     y = detailslist[0]

In the past, rel-eng has created empty updates/14 and updates/testing/14 repositories, to handle this.  I don't want MM to have to know that undiscovered, "future" repositories should really be just empty.

bah, one more patch to add back in the <?xml ?> section.  Ooops.  That's pushed upstream now too.

I created the directories now, and added the creation to our SOP.