If you decide to install shared software for the department, please look over the current guidelines for doing so.

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):

Firefox 1.5 (final) 2005-12-15 post  
Hugs 98 March 2005 2006-2-13 kelsey Haskell 98 Interpreter
keychain 2005-10-10 kelsey ssh-agent support
maxima 5.9.1 2005-12-19 gildea  
R 2.2.0 2005-12-15 post  
Emacs Speaks Statistics 5.2.11 2005-12-15 post how to use this
Subversion 1.2.3 2005-09-20 kelsey Versioning system.
tidy   2005-08-17 kelsey HTML cleaner.
vsound 0.5 2005-02-16 kelsey virtual audio loopback
xdiskusage 1.48 2005-08-03 kelsey frontend to du.
xxdiff 3.0.4 2005-10-28 kelsey frontend to diff
zgrviewer 0.3.1a 2004-11-22 kelsey A Java graphviz graph viewer.


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

First: I think the assumption should be that if you wants a new version of something that someone else installed, mention it to that person first. It doesn't seem worthwhile to state explicitly whether one plans to actually maintain something.

Second: Having a consistent naming scheme in everyones $HOME would be nice, but I think its more important that people separate things they really intend for general consumption (i.e. separate ~/local/bin/ and ~/share/bin/). This will reduce the amount of cruft in /usr/grads/.

Omega: The problem with actually building in /usr/grads/ is that anyone can pile crap in there that noone else cares about. If you want something enough to install it, my feeling is that you should own it until someone else wants to take over, or get rid of it. I don't see having old versions of things floating around in peoples directories as an issue.

Having a myriad of links around the ~'s seems poor-form, but the sys-admin's policy on actually installing something includes keeping the source around, and having a makefile that someone else can run to recreate the binaries. Thats a lot to keep in one place.

My biggest concern is about permissions. In either case once someone installs something it cannot be replaced by another person. It looks like the sticky bit is the problem, but I don't know if I think taking it off is really better.

-- KirkKelsey - 21 Dec 2005

Okay, so I just went ahead and changed the layout to be a table. If you don't like it, just revert to an ealier version. Getting TablePlugin would make it a bit nicer.

-- KirkKelsey - 21 Dec 2005

Added a link to the SoftwareGuidelines pages. The discussion should move there

-- KirkKelsey - 14 Feb 2006

Edit | Attach | Watch | Print version | History: r26 | r11 < r10 < r9 < r8 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r9 - 2006-02-14 - KirkKelsey
  • Edit
  • Attach
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding URCS? Send feedback