[25973] in Source-Commits
Re: /svn/athena r25235 - trunk/debathena/scripts/installer
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Sat Jul 30 09:55:59 2011
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <201107142021.p6EKLmVh003069@drugstore.mit.edu>
Date: Sat, 30 Jul 2011 09:55:52 -0400
Cc: source-commits@mit.edu
Message-Id: <7575B0AF-3C4F-42D0-9022-A93347B9A19E@mit.edu>
To: "andrew m. boardman" <amb@mit.edu>
Content-Transfer-Encoding: 8bit
On Jul 14, 2011, at 4:21 PM, andrew m. boardman wrote:
> Author: amb
> Date: 2011-07-14 16:21:48 -0400 (Thu, 14 Jul 2011)
> New Revision: 25235
>
> Modified:
> trunk/debathena/scripts/installer/install-debathena.beta.sh
> Log:
> Choose exactly the known repos listed in hesiod for apt sources. In
> particular "development" no longer will imply "proposed".
I now remember why we originally had "development" imply "proposed": It is not supported for Hesiod clusterinfo to have two unversioned labels of the same name. Using getcluster(1) on an alpha machine, you only ever see apt_release=development (because it's the last one in the list). But the installer uses dig and sees the full list. So either we need to patch getcluster to concatenate similar tags together, or we retain the auto-updater's functionality that development implies proposed. Frankly, I'd be in favor of the former. So, for example:
apt_release proposed
apt_release development
would be translated by getcluster -b to
APT_RELEASE="proposed development"
It's unclear that it's worth it, but at the same time, the current system feels like we'll forget something at some point.
Thoughts?
-Jon
