The project was successful in that a full version of DICE based on Fedora13 was developed and is now in use in the School. The project was delivered mainly on time with a two week delay caused by switching the target platform from F12 to F13. As seems to be usual with these ports the 64 bit port has lingered and has been considered largely complete apart from a small number of rpms which can be built on demand. With the MPU slimming down the inf level platform a number of standard rpms (i.e. rpms in F13 repositories) fell between the dice and lcfg layers and were dropped. Initially we added those requested by users to the RAT "env" package lists but this resulted in problems in applying Fedora updates. The packages were ultimately moved into a new dice_desktop package list and we're currently looking at ways to implement upgrades less painfully.


  • Automating the process of upgrading rpms and where necessary rebuilding them was very successful. Use of the build farm and the ability to build packages for multiple platforms should make it even easier.

  • One drawback of using mock was that, building from existing SRPMS is wasn't possible to build new RPMS and SRPMS at the same time and so RPMS had to be submitted -x

  • We seem to have lost track of software requirements with a fair number coming out of the walls very late on into semesters.

  • We have to a certain extent re-invented the ed layer in that we have a package list full of standard "unixy" commands which are not required for an lcfg level machine, are standard with F13 and need to be kept up to date but which are not specifically required for research and teaching.

  • A significant amount of the CO effort expended was in upgrading or patching a relatively small number of packages (say 60% of time on 10-20% of packages) We probably ended up expending CO effort on software which is not used and may not have been used for some time.

  • Some Academic staff are running teaching software our of their home directories rather than asking us to package it or running it out of group space or more sensible networked filespace.

  • By automating rebuilds of sl5 rpms we have held a number of rpms at versions dating from when sl5 shipped....this may not be a good idea.

  • We would often require a large number of devel type rpms to build individual rpms, yum was indespensible for doing this,


  • We need a database of software required for teaching. Ideally this should have some mechanism for allowing staff to query the repositories we use for software
  • We should probably have a similar database for research software to inform us of what's required and inform users what's available.
  • The research and teaching package lists should be culled of packages which are not for specific teaching or research requirements and if still deemed useful these packages should be put somewehere more appropriate where they can be upgraded automatically as rpm become available .


  • Effort involved was approx 14 weeks, this includes the duplication involved in switching to F13 late on and some overhead in moving packages from an edinburgh environment layer to RAT and a subsequent reworking of the ghc packages.

-- IainRae - 02 Mar 2011

Topic revision: r4 - 12 Apr 2011 - 19:30:24 - IainRae
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies