This is similar to what is done with other Yum repository metadata.

It is not just about consistency though, it fixes real issues.

For example, at work, we use the Amazon CDN to implement mirroring of
our Yum repositories. All files are cached on the CDN for the default
duration (i think it's 24 hours), except repomd.xml which is never
cached.

This works great for RPMS (they never change once published) and all
the metadata files (their names are prefixed with their hash, and as
such the CDN sees them as different files).

However, we keep running into trouble with updateinfo.xml.gz: the CDN
keeps distributing the old file even though a new one was generated.

Because the updateinfo metadata can be quite big, we'd rather prefix
its name with a hash (like other Yum repository metadata), and let the
CDN handle it, rather than telling the CDN to never cache it, which
would put more load on our primary repository server.

All other Yum repository metadata are already using this stronger hash,
so let's be consistent and more secure.

If someone tries to uncomment these for debugging purpose, they might
not realize that they don't reflect reality any more, and might waste
lots of time trying to figure out what is going on.

Now that we prefix the file name with its hash, each written file will
have a different name.

As a result, we need to remove the previous versions when we load it,
otherwise we end up accumulating updateinfo.xml.gz metadata files.

Now that we prefix the updateinfo metadata with its hash, the Bodhi
masher must be taught to find it.

The bonus point of using a glob is that it even handles migration from
non-prefixed to prefixed file name. :)

This assertion was failing due to a syntax error in my masher/updateinfo
code.

Adding this message allowed me to find it quickly, and it could be
useful in the future.