Add compatibility with legacy screens and avoid duplicate records #70
Conversation
simon-ess
force-pushed
the
expand_config_env
branch
from
c0c5044 to
56f5735
Compare
simon-ess
left a comment
simon-ess
left a comment
There was a problem hiding this comment.
I'm not sure that I really love this change. I don't think that maintaining legacy PVs is something that a given EPICS module should be responsible for; changing the module's interface is simply a thing that will happen over time; if legacy PVs are needed then I think each individual site should take care of that themselves.
That said, if the PVs are being dropped intentionally, it might be worth making sure that I have clear release notes and possibly increasing the major version...
iocAdmin/Db/legacyEnvVars.db
Outdated
| @@ -0,0 +1,16 @@ | |||
| alias($(IOCNAME):CA_ADDR_LIST, $(IOCNAME):CA_ADDR_LIST) | |||
There was a problem hiding this comment.
This alias is not needed.
There was a problem hiding this comment.
Oops, sorry, missed this one. Thanks for catching that.
The idea was to offer flexibility and a soft-transition from one version to another (you can choose to load the db file or not). On occasion, my group ends up with different OS versions on our VMs (which translates to different versions of certain packages), but we want to keep shared screens for things like iocStats, etc. I try to keep our packages fairly close to upstream, but sometimes it is hard to convince all users of a package that they'll need to update their screens/scripts/routines. Offering a soft-landing to the new version usually helps with that. That said, I'd be willing to maintain this internally if this makes more sense to the maintainer team. |
|
For the APS Accelerator systems we now copy the OPI screen files from the support module versions that each IOC application area builds against into a screens area for that IOC application area. I introduced that into our system design to avoid this problem of the module PV interfaces changing, since we have many different versions of the support modules in use by our IOCs. It means we now have 62 copies of the iocStats screens installed, but they match the iocStats databases that the IOCs loaded, and disk space is cheap. The same applies to things like asynRecord screens, mrfIoc2 screens etc. which have changed slightly over time. I don't object to maintaining legacy PVs in iocStats though, our installation is probably unique in having a solution to this problem and we certainly used to rely on continued support of older screen files. Our IOCs do load .db files containing aliases for that reason. |
simon-ess
force-pushed
the
expand_config_env
branch
from
56f5735 to
5ca094e
Compare
nariox
force-pushed
the
expand_config_env
branch
from
07ff66d to
4e4ed0c
Compare
|
Closing as this work was included as part of #69 |
3 participants
Hi Simon,
I included a minor change to avoid duplicate env vars from showing up in the file (mostly in case someone redefines something in
CONFIG_SITE_ENV) and also created a file that generates aliases from the env var name to the old naming convention (3.2 and earlier). Let me know what you think.