Porting Teaching/Research Software Procedures

Introduction

Follow these guidelines when porting software from one DICE distribution to another.

The lists of software to port are here:

Software packages highlighted in orange have yet to be ported.

Simply pick a piece of software from this list to look at and follow the guidelines below. Once a completed package is available for the new platform either let the rat-unit know so the database can be updated or if you have access update it yourself (see Database section).

These procedures cover the majority of the software packages, however a few are different (such as where multiple versions of the same software are required installed in parallel or the software is automatically packaged from our CVS repository - these edge cases are not covered here, just ignore these packages if you come across them).

Local or External

First it is useful to know whether the package for the software has been:

  • crafted and built locally
  • obtained from an external third party and just rebuilt locally
  • just added from the Extras repository of the distribution

We can check this by looking for the package associated with the software in the Subversion repository in:

  • core/packages/dice/dice_fc6_teaching_and_research.rpms
  • core/packages/dice/dice_fc6_i386_teaching_and_research.rpms (packages not built for 64bit)

Note that the names of the packages in here are not always exactly the same as listed on the software pages above, although any difference is usually obvious enough.

If the package is local it should have a .dice or .inf tag at the end of the release, if not it will have a .fc6 tag. Note some packages contravene this rule. In order to see whether the package has come from an external source or is just from Extras you need to check whether it is held in:

  • /pkgs/master/rpms/fc6/dice (from an external source and rebuilt locally)
  • /pkgs/master/rpms/fc6/extras (in the extras repository)

Extras Packages

If the package was in Extras then see if the same or newer version exists in either the base distribution or the Extras distribution for the new platform, check:

  • /pkgs/master/rpms/sl5/base
  • /pkgs/master/rpms/sl5/extras

If you find it in base then you don't need to do anything as its part of the distribution already and we no longer need to locally maintain it, you can double check by doing rpm -q PACKAGE on an SL5 machine.

If its not in base but is in extras then its simply a case of adding the package to the appropriate software list:

  • core/packages/dice/dice_sl5_teaching_and_research.rpms

and submitting the updated file. Doing an om updaterpms run after profile builds on a develop SL5 machine should then install the package and it can be tested.

If the package is not in either base or extras or the version in base or extras is older than the version on the current platform then it means it is effectively no longer part of the default distribution and we will have to start maintaining it. The simplest start point for doing this is to grab the package source from Extras on the old platform and attempt to rebuild on the new platform. Get the package source from:

  • ftp://download.fedora.redhat.com/pub/fedora/linux/extras/6/SRPMS

and then try building it, see Build section.

If the package does not rebuild see the section below on Failures.

External Packages

If the package was rebuilt locally from an external source then first check to see whether the same or newer version is now available in either the base distribution or the Extras distribution for the new platform, check:

  • /pkgs/master/rpms/sl5/base
  • /pkgs/master/rpms/sl5/extras

If you find it in base then you don't need to do anything as its part of the distribution already and we no longer need to locally maintain it, you can double check by doing rpm -q PACKAGE on an SL5 machine.

If its not in base but is in extras then its simply a case of adding the package to the appropriate software list:

  • core/packages/dice/dice_sl5_teaching_and_research.rpms

and submitting the updated file. Doing an om updaterpms run after profile builds on a develop SL5 machine should then install the package and it can be tested.

If the package is not in either base or extras or the version in base or extras is older than the version on the current platform then we need to continue to maintain the package.

First check to see if there is a newer version of the SRPM available - you can look at the URL in the software lists above or rpm -qip PACKAGE.src.rpm should also have a URL to check. If there is a newer version of the SRPM then download that, and then try building it, see Build section. If the package does not rebuild see the section below on Failures.

There might not be a newer version of the SRPM available but there may be a newer version of the software available. If so then use the existing SRPM with the newer software - see the Local section.

If there is no suitable SRPM available then take the existing SRPM from:

  • /pkgs/master/srpms/fc6/dice

and then try building it, see Build section.

If the package does not build see the section below on Failures.

Local Packages

First its worth trying out the package for the existing platform to see it it builds and runs on the new platform. You can get the SRPM from:

  • /pkgs/master/srpms/fc6/dice

and then try building it, see Build section. If the package does not build see the section below on Failures. If it does build then this provides your fallback package. However you probably want to do a number of other things first. Check to see whether the same or newer version is now available in either the base distribution or the Extras distribution for the new platform, check:

  • /pkgs/master/rpms/sl5/base
  • /pkgs/master/rpms/sl5/extras

If you find it in base then you don't need to do anything as its part of the distribution already and we no longer need to locally maintain it, you can double check by doing rpm -q PACKAGE on an SL5 machine.

If its not in base but is in extras then its simply a case of adding the package to the appropriate software list:

  • core/packages/dice/dice_sl5_teaching_and_research.rpms

and submitting the updated file. Doing an om updaterpms run after profile builds on a develop SL5 machine should then install the package and it can be tested.

If the package is not in either base or extras or the version in base or extras is older than the version on the current platform then next check to see whether a version now exists externally that we can use. Do a web search for the PACKAGE .src.rpm for example. You could also check the URL in the software list above to see if they now distribute the software with an RPM. Alternatively you could also check one of the repository sites such as rpmfind.net to see if there is a version there (perhaps for another distribution). If you find an external source for the SRPM then download it and try building it, see Build section. If that works then use this on the new platform instead. If the package does not build see the section below on Failures.

If no suitable SRPM can be found for the software on the web then we need to continue using our existing local package which we have built already as a fallback. However there may be a newer version of the software. Check for this first. If there is a newer version of the software then download this and update the package .spec file to use the newer version and then try building it, see Build section. Often this will just work, if it does then the new version can be used on the new platform. Just as often it will not just work, see the section below on Failures for addressing this.

Build

Given you have a .src.rpm file from somewhere then on buildsl5 do rpm -i PACKAGE.src.rpm and then cd $RPMROOT/SPECS and then rpmbuild -ba PACKAGE.spec. Sometimes the specfile isn't obviously named, doing rpm -qlp PACKAGE.src.rpm (what you downloaded from the ftp site) will return the name of the .spec file. Assuming that works and the package builds then submit it to the appropriate repository with /usr/sbin/rpmsubmit -B world PACKAGE.i386.rpm and add it to the appropriate software list:

  • core/packages/dice/dice_sl5_i386_teaching_and_research.rpms

then doing an om updaterpms run after profile builds on a develop SL5 machine should install the package and it can be tested. If that works try rebuilding on buildsl5_64. If that works the package can be added to the standard list:

  • core/packages/dice/dice_sl5_teaching_and_research.rpms

and deleted from the one above.

Failures

If the package failed to build (or built and failed to run correctly) then it needs to be fixed. Often this can be fixed simply by searching the web for a newer version of the SRPM or a newer version of the software. If neither of these provide a working package then simply ignore the package for now and look at another one and seek assistance to fix it later.

Database

The pages with the list of research and teaching software are generated by the database every morning. When packages are ported to the new platform the database should be updated, also when new packages are added. To update availability start the database (using the tecdat command) and open the Teaching-Software display (using the Display->Open menu option) and search for the package (see Query Mode Syntax). When you have the package displayed click on the tabular entry field in the Software-Version area and you should get a cursor. Step down (with cursor keys) until you get a new record with a plus symbol beside it. Now enter the session the software will be available from (07, 08, etc), the version of the software that will be available in that session, then right click on the Status column cell and choose Available from the pop up menu. Finally click on the Okay button to save your changes.

To add a new package you need to use tables directly rather than a form. Open the Teaching Software table (using the Display->Tables menu option). Clicking Okay once the table has loaded on the main window will show you all the existing software. Click Add New Rows button to add a new record. Enter a short unique mnemonic in the Software@ field, a quick description of the software in the Title field and in the URL field put the website where the software can be downloaded from. Then click Okay to save the new record. Now search for the record by clicking on the Query Rows button and enter your short mnemonic in the Software@ field and clicking Okay. You should have your new record displayed. Now click on the Sftwr-Requirement link button to link to another table. Click Add New Rows and add details on who requested the software - you will need to fill in the Person@ field (use the Lookup Person form from Display->Open menu option to get this id) and possibly the RT number in the Ticket field. Click on Okay to add the requirement details. If this is software for a teaching course rather than a specific research request then do similarly except use the M-Sftwr-Requirement link button. You will need to fill in the Session@ field with the session the software is required for and the corresponding Module@ field (use the Utilities->New Window menu option to get a new window and then Display->Tables menu option and select the Module table to look up the course code to use).

-- TimColles - 23 Apr 2008

Topic revision: r4 - 16 Apr 2012 - 15:02:16 - GrahamDutton
 
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