Camera geometry used to be defined using PAF (policy) files, which are now deprecated. As part of the transition to the refactored camera geometry scheme, scripts were introduced to convert from the PAF files to the new camera geometry configuration scheme which uses FITS files and a python file to describe the camera. These scripts ("genCameraRepository.py" in obs_cfht, "makeLsstCameraRepository.py" in obs_lsstSim, "makeDecamCameraRepository.py" in obs_decam) are still part of the obs_* packages, and some people rely on them for making changes to the camera description. On the other hand, the generated FITS files and python file are also first-class members of the obs_* packages. This means that we have two sources of the same information, which is dangerous. What should be viewed as the primary source? The options appear to be:
1. The generated FITS files and python files are primary, and the conversion scripts were temporary, intended for the transition only. This is the approach we have taken in obs_subaru, where we have deleted the conversion script as a relic of the past and track only the FITS tables because that's what the CameraMapper uses; the disadvantage is that changes to the camera geometry require editing the binary FITS tables. If this option is accepted, we should delete the conversion scripts in all obs_* packages.
2. The conversion scripts are primary, and the generated FITS files and python files are just a cache for the CameraMapper to read. This provides a readable and easily editable source, but requires additional steps to generate what the CameraMapper will use. If this option is accepted, we should delete the generated FITS files and python files from the obs_* packages and generate them at build time. We should also update the conversion scripts to use a different source than the deprecated PAF files (e.g., YAML).
3. Some other source is primary. Maybe the FITS files weren't such a great idea because they're hard to edit, and we should specify our camera geometry purely in python. This is the approach taken in obs_monocam. However, Monocam has only one CCD, and maybe this wouldn't be feasible for cameras with a hundred CCDs.
It may be that this choice could be different for different obs_* packages depending on the preferences of the maintainer, but a choice needs to be made for each.