[6709] in Release_7.7_team
Re: thirdparty packages
daemon@ATHENA.MIT.EDU (Alex T Prengel)
Fri May 7 15:01:38 2010
From: Alex T Prengel <alexp@MIT.EDU>
To: Jonathan Reed <jdreed@mit.edu>
Cc: "release-team@mit.edu" <release-team@mit.edu>, alexp@mit.edu
In-Reply-To: <107A1C3A-0E49-46BD-BC39-43AEB7D63D5C@mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Fri, 07 May 2010 15:01:28 -0400
Message-Id: <1273258888.27804.82.camel@dit.mit.edu>
Mime-Version: 1.0
On Fri, 2010-05-07 at 14:03 -0400, Jonathan Reed wrote:
> > So clearly there's not enough time for detailed review but some general
> > thoughts below. I'd feel a lot better if we had at least a full semester
> > before we make significant deletions. Also, what machines are being
> > monitored? I presume cluster only. Is is all of those?
>
> Yes, just -cluster machines. But this means any machines running -cluster, regardless of whether they are physically located in a cluster).
>
> > There's a number of things that I know get used...
>
> Sure, and if there are packages requested by courses, they should stay. However, you mention wrapper logs for pymol -- if people are all using the pymol from the locker, and not the local version, then is there any point in us continuing to ship it locally? (rhetorical question)
Legacy locker- from before the Unubtu version was being used.
> My primary point is this: It's not sustainable for us to continue installing EVERYTHING both in lockers and in -thirdparty. It also does a disservice to the users if we have N different versions of the same software floating around. And it makes support harder. If there's stuff that's better suited to lockers, then it should stay in lockers. If there's stuff that's only in lockers because we had no way of putting it in the release in Athena 9, then it shouldn't go in lockers.
Yes, I agree, sure. Virtually all the packages you mentioned are not
being maintained in lockers any more, though some are hanging around
from before.
>
> We've talked before about the corner case where a professor needs a bleeding-edge version of software that's newer than what's in Ubuntu. And that's fine. But my point is that we need to come up with a consistent policy, and most importantly we need to stick to it. Lockers have a number of benefits -- they're easily to centrally deploy and configure, and they're accessible to anyone using AFS, not just Athena users. But this might be a good thing and a bad thing, and we need to think about what we actually want. And this may mean pushing back on some requests for locker software, and it may mean pushing back on requests to have things added to -thirdparty.
>
>
> There is the argument that disk is cheap, and network is (or should be cheap), so we should just install everything. But (and maybe I'm alone in this view, and if so, I'll stop bringing it up) it just seems wrong to install EVERYTHING on local disk and in lockers and then hope for the best.
Just to be clear- I'm absolutely not intending to maintain things in
lockers that are available as Ubuntu packages, except for a very few
special cases-
Ubuntu package is broken
Application takes a lot of special add-ons (like R)
Faculty member/others insist on bleeding-edge release for valid reason
I do think we ought to supply a fair number of scientific apps that do
come as Ubuntu packages, and I understand that we need to be selective
about that.
A.
