[6997] in Release_7.7_team
Re: Maverick support
daemon@ATHENA.MIT.EDU (Jonathan Reed)
Tue Oct 12 00:16:03 2010
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Jonathan Reed <jdreed@MIT.EDU>
In-Reply-To: <alpine.DEB.1.10.1010112306050.22003@dr-wily.mit.edu>
Date: Tue, 12 Oct 2010 00:15:51 -0400
Cc: release-team@mit.edu, debathena@mit.edu
Message-Id: <ABE09435-5EE9-4161-90F3-9698E6628EA1@mit.edu>
To: Geoffrey Thomas <geofft@mit.edu>
Content-Transfer-Encoding: 8bit
On Oct 11, 2010, at 11:19 PM, Geoffrey Thomas wrote:
> I intend to move Maverick's packages to production tomorrow morning
A ~12 hour window on a holiday weekend for comment on a new release feels kind of short.
> enable maverick support in the installer shell script, and send mail to this effect to debathena-announce and release-announce, assuming I receive no reports of issues between now and when I wake up. Liz, Ben, and I have all installed Debathena on Maverick and things seem fine.)
3 data points really doesn't feel like a good enough test of a brand new distro to me. I haven't even tested it yet. Also, which metapackages did you install? Did testing consist merely of installation, or anything else?
I think we need to start setting end-user expectations appropriately. Therefore, I would propose that until we get some additional testing, particularly of -workstation, I think that maverick support should be added to the installer as such:
===================================================================
--- install-debathena.sh (revision 24892)
+++ install-debathena.sh (working copy)
@@ -187,6 +187,13 @@
hardy|intrepid|jaunty|karmic|lucid)
ubuntu=yes
;;
+maverick)
+ output "Maverick is still undergoing additional testing, but is believed to"
+ output "be functional at this time. However, if this is a mission-critical"
+ output "workstation or production server, please proceed with caution."
+ output "If you encounter any problems during installation, please report"
+ output "them to debathena@mit.edu."
+ ubuntu=yes
*)
error "Your machine seems to not be running a current Debian/Ubuntu release."
error "If you believe you are running a current release, contact debathena@mit.edu"
This allows bleeding-edge users to install it immediately, but lets novice users know this may not be what they want. (Yes, I realize they've already installed Maverick by the time they run the installer, but still.)
> 1) There's an upstream bug in Maverick's libc apparently tickled by the combination of nss_nonlocal being used and disabled by $NSS_NONLOCAL_IGNORE that can cause cvs's postinst to crash when creating /srv/cvs. The package manager reattempts the postinst and the installation completes fine, but /srv/cvs is not properly created. Since I'm not really aware of people using /srv/cvs as opposed to a real repo somewhere else, and also since we can't fix this on our end, I'm not considering this a blocker. The bug was fixed upstream shortly after the release that Ubuntu took for Maverick, and Anders has filed an Ubuntu bug at http://bugs.launchpad.net/bugs/658907
> Because cvs has not been updated in Ubuntu since Jaunty, this only affects new installs.
We should document this somewhere (i.e. Hermes).
> 2) Upstream from now uses the "alternatives" system, so our diversion of /usr/bin/from to install the one from mitmailutils may not take effect. This only affects upgrades because with new installs, we successfully divert the symlink to /etc/alternatives/from. On upgrades, that symlink beats our symlink to from.debathena. I've filed a ticket at http://debathena.mit.edu/trac/729 but the lack of "from" doesn't particularly feel like a release blocker to me.
I'm not really ok with this. "from" is in the default dotfiles, and users are going to notice those error out and ask OLC about it. It seems like it's probably a quick fix, and therefore we wouldn't be delaying the release by too long.
I know we want to have Debathena out and supported as close to the release date as possible, but Debathena has much more exposure now, and we maybe need to sacrifice bleeding-edge support for a bit of polish.
-Jon
