Shared software installed in /usr/grads

Really, we should find a way to have user-installed software all in one place, rather than in lots of separate places. This would save us disk space as well as time, so this page is an attempt to start doing that.

Here is the software currently installed in /usr/grads (likely incomplete):

Discussion

Since there are a lot of cooks that have access to the /usr/grads pot, in the list above I have implemented some conventions. The list will be alphabetical, contain the software name, relevant links, and version number, and will be concluded with the date it was last updated, and by whom. Please feel free to discuss / argue / refine this below.

-- MattPost - 16 Dec 2005

There is very little space available in /usr/grads/. I think the best solution is to continue installing things wherever one likes, but linking to it in /usr/grads/. This also has the advantage of allowing one person to upgrade the software without actually removing someone else's installation. We should figure out how to easily ensure that binaries and (e.g.) man pages both get linked.

Also, its nice to have a description for unfamiliar things.

-- KirkKelsey - 16 Dec 2005

The system used at CMU is that a specific individual (staff/grad/whatever) claims responsibility for a particular package. In their case this extends all the way to things like gcc. I was/am a big fan of that arrangement. I am in favor of boosting the size of /usr/grads/, or perhaps a more generic /usr/contrib/, and then having people register via the wiki in a format much like Matt has proposed. As an additional field one perhaps might note whether they are planning on being responsible for future updates, or at least would like to be told/warned before someone else performed an upgrade. For instance, I (maybe?) have the newest version of Gaim in the department, but have no interest in updating it (I have version 1.4, there have been multiple releases since then). But something like emacs, Matt and I practically raced each other to grab the head out of cvs once news of stability came out; I'd have no problem being in charge of keeping that bleeding edge.

The benefit to Kirk's suggestion is that it is easy to update something you care about all the time, without worrying about possibly hurting other people that rely on that package (although this really doesn't solve anything, it just makes the maintainer feel better, as they can shirk the label "maintainer"). Since people can still install things locally even if we did adopt something like what Matt suggests, then I don't see this as a strong enough argument to keeping things the way we are going. This is especially true when I think about 6 years from now when we have a crazy number of libraries and executables criss-crossing the user directories, after all of those users have left and no longer respond to emails.

If we do decide that we want what Kirk suggests, I think at the very least we should try to adopt a standard organization scheme within each user account, in addition to having a procedure for properly linking libraries, executables and binaries into /usr/grads/ (as Kirk said).

-- BenjaminVanDurme - 20 Dec 2005


This topic: Main > WebLeftBar > TechTalk > SoftwareStuff > SharedSoftware
Topic revision: r5 - 2005-12-20 - BenjaminVanDurme
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback