Opened 17 years ago
Last modified 17 years ago
#1212 new defect
dvo.site should be generic
| Reported by: | Paul Price | Owned by: | eugene |
|---|---|---|---|
| Priority: | lowest | Milestone: | |
| Component: | DVO | Version: | |
| Severity: | trivial | Keywords: | |
| Cc: | jester@… |
Description
Since the dvo.site is supposed to be copied into the home directory as .ptolemyrc, it needs to be able to select different builds. With the .ipprc file, this is done using environment variables (e.g., $PSCONFDIR)
This is not a big deal at the moment, since the builds have been consistent for the DVO files.
Change History (2)
comment:1 by , 17 years ago
| Cc: | added |
|---|
comment:2 by , 17 years ago
Just realized (again by bad experience) that it's worse: there needs to be a mechanism for pantasks to launch jobs on other machines with a PSVERSION that's set by the $PSVERSION under wich pantasks was started, and not by the psconfig in the remote machine's and user's ~/./bashrc or ~/.cshrc

Same goes for system.config, site.config etc. Different versions of IPP require different things to be present in these config files (e.g. a system.config that references masks.16bit.config in the RECIPES section will make an older IPP version unhappy because it didn't have that config file).
Since in principle also the structure and content of ~/.ipprc can change for different IPP versions, I don't think $PSCONFDIR is quite enough. ~/.ipprc.$PSVERSION should work, shouldn't it? Same for the other config files.
In fact, I think having full psconfig version switching between all aspects of different IPP versions is essential to having a reproducible production environment, so I would suggest renaming this ticket to "All config files should be psconfig-versionable", setting component to psconfig, consider it a blocker as far as the production system is concerned, escalating this to maximum priority.
(I thought I'd filed a similar ticket before but can't find it now...)