Version 5 (modified by jdreed, 9 years ago) (diff)


Notes About Specific Packages


Location in the source tree: debathena/debathena-thirdparty

The purpose of this package is to provide "third party software". Historically, "third party software" was software installed in lockers, and not in the release. This includes commercial software like MATLAB, but also included a lot of Free Software, because back in the day, the base system didn't include a lot of the packages that are commonplace in Linux distributions. So the name is now a historical accident, but the purpose of this package is to depend on other packages in Ubuntu, to ensure they're installed on debathena-cluster machines and the dialups.

Because the list of packages changes across Ubuntu releases, it's difficult to make this a one-size-fits-all package. So it generates its list of dependencies at build time. We specify what packages we want, and we have per-distribution override lists. Internally, it uses the chdist program to determine what packages are available for what distributions. If we depend on a package, and that package is not available, the build will fail.

See BUILDING in the package's directory in the source tree for a detailed explanation of the syntax of the lists files. But basically, updating this package consists of making a change either to lists/common (to pull something in on all distros) or lists/distro-codename-goes-here to pull something in on specific distros.

OpenFoam and the APT repo

precise and trusty add additional packages to the APT repo. The OpenFoam? package provides .deb files. We do not add PPAs on the fly to cluster machines, because sometimes bad things happen, and a repo being down will cause the auto-updater to break. So we download the .deb packages for OpenFoam?, and add them to our repositories for precise and trusty with dareprepro includedeb <codename> <deb-file>. We then list those packages in the distro-specific lists above, with a +, to indicate that the package should not attempt to verify their existence at build time.

This is a hack and we should probably not do this again.


See BUILDING.debathena in the root level of the moira submodule.

The primary goal of the instructions there is to get a snapshot of the moira repo into our repo. You may accomplish this any way you like.

This is a non-native package, so as with any non-native package, ensure you commit changes to master and tag the release with the upstream version number. (Noting that you will have to delete the tag imported from the ops moira repo, since it will have the same name).