Experimental Physics and
Industrial Control System

I think a major issue that I faced and I could find a systematic solution for it is the use of SHRLIB_VERSION variable during build. This will cause your application/module/etc. to be linked against this version only and if you updated a certain module, the linker will fail to find the needed libraries. I discussed this issue previously https://epics.anl.gov/tech-talk/2022/msg01314.php and it seems it is better to set it to overcome any critical ABI incompatibility issues. This raises few questions about how to implement an update policy in the RPM repository:

1.       How to determine if an update for a certain module need? For example, say you want to update sequencer module from 2.2.8 to 2.2.9 therefore you have to update all modules depending on the seq module directly or indirectly.

2.       How to handle this update policy in RPM spec files? If you updated seq you will have to re-build asyn for example but you keep the same asyn version, therefore the new RPM package won’t appear in yum install. A possible solution here would be to increment the “Epoch” value of the spec file.

3.       Maybe we can group RPMs into a single software package? Something like synapps and have its own version number based on RPMs versions contained within?

 

Any comment is appreciated.

 

Best Regards,

Abdalla.

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Lucas Russo via Tech-talk
Sent: Wednesday, February 1, 2023 10:58 PM
To: Ralph Lange <ralph.lange at gmx.de>
Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: Re: EPICS deb/rpm packaging