The apt_release clusterinfo tag is Wrong(tm)

[jdreed]

It is not supported to have multiple unversioned clusterinfo tags, and we do just tag for -dev and -proposed. The installer (see #164) and auto-update query Hesiod directly (which is also Wrong(tm)), but we should come up with a way to do this that plays nice with getcluster. I suggest deleting the apt_release tag (since it's pointless to have a value of "production", which is ignored) and creating a extra_repos tag or something, which has comma-separated values (is this supported? we could use another delimeter). That way this is fixed, and we don't have to worry about the case that development implies proposed.

[jdreed]

-development does in fact imply -proposed, and must continue to do so unless we change our workflow, and we're not doing _that_.

Here's where we use APT_RELEASE and how we treat it:

• auto-update: development implies proposed
• the installer: queries Hesiod directly, development does not imply proposed

Possible solutions:

• Punt apt_release in favor of a "sourceslist" tag pointing to a sources.list file in AFS, though we'd either need one per distro/release or we'd need to swap in the codename.
• Decide that development does imply proposed, and that bleeding implies development + proposed
• Something else

[jdreed]

I have asked ops to pull the duplicate apt_release "proposed" value from alpha-linux. We'll test a '+' delimited "extra_repos" tag in bleeding. (I think '+' is the safest character to use without quoting, I'm open to other suggestions)

[jdreed]

Installer fixed in r25838