Thanks a lot for your reply. One reason I'm interested in this issue from an scientific research perspective is that the requirements that you have aren't unique, and figuring out how to make the release and packaging processing work with the needs of science is an interesting problem.
On Fri, Aug 16, 2013 at 1:11 AM, Scott Rankin <srankin@xxxxxxxx> wrote:
1. Users must be able to install several versions of CASA with any mixture of major,minor versions on a system at the same time.
This shouldn't be a major problem as the distributions have mechanisms for allowing multiple kernels and system libraries to coexist. Also this is a general issue for theory code, as the user would like to have multiple versions of the code to do before and after experiments.
2. We publish stable packages monthly and release packages every 6 months.
This is a faster rate of change than many Linux distributions can absorb. This may not be an issue if you are maintaining separate package repositories.
I also don't think this is a major issue as the newest code can be put in the test repository.
3. In some cases, we must use non-standard versions of packages already included in distributions because the version included in the distribution is either too different from the versions used on other distributions, or has bugs we can't afford to work around.
Yes. This is an issue. I'm hoping that we can reduce the need for special packaging my making sure that bug fixes are put upstream, and that there is not much forking.
4. CASA packages must be self contained (as much as is practical) to prevent changes in 3rd party code from changing its behavior.
Again, this is a reasonable requirement. The difficulty here is that by using internal 3rd party code, science software has put itself in a situation where the 3rdparty code used is non-standard and does not get bug fixes and enhancements that are available as the 3rdParty code is improved.
Trying to figure how to get reproduciability without forking is an interesting research problem. The issue is that astronomy software has evolved so that essentially everyone is running their their custom version of WCS and AST, and it is impossible to share bug fixes and improvements because the versions have diverged so much.
Trying to figure how to get reproduciability without forking is an interesting research problem. The issue is that astronomy software has evolved so that essentially everyone is running their their custom version of WCS and AST, and it is impossible to share bug fixes and improvements because the versions have diverged so much.
Because of these requirements, which we do not yet meet on either RHEL or OS X, we are planning major changes to our packaging and distribution system to package CASA and any non-standard libraries we need for installation in /opt/casa/.
These requirements may make CASA packages we produce unacceptable as standard packages from many Linux distributions.
As long as the packages are generating using the standard rpmbuild package, it should be possible to adapt the packages to the standard distributions.
If this does not put you off, I'll be happy to discuss this further, so long as this does not take time away from my primary assignments.
Sure. No problem. These are general issues that hit all scientific software, and trying to deal with them would be very use. One thing that we can start with is if you can point me to a document or wiki page that explains what the release process should me. If the packages are built using rpm spec files, then it's going to be easy. If not, then I'd like to focus on understanding your release mechanisms so that we can generate rpm spec files with minimal effort on our end.
_______________________________________________ Fedora astronomy mailing list astronomy@xxxxxxxxxxxxxxxxxxxxxxx http://fedoraproject.org/wiki/SIGs/Astronomy https://admin.fedoraproject.org/mailman/listinfo/astronomy
