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(a)nrao.edu> 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.
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.
