RE: Basic EPICS bootstrap (rant)

[Abdalla Ahmad via Tech-talk <tech-talk@aps.anl.gov>]

I would like to share our work on this subject which has been working very well for many years now, if anyone is interesting in RPM packaging.

 

I had two issues with EPICS build system: build time and location of EPICS modules, it has been somewhat a time consuming task; whenever I had a new workstation or server, or a new IOC to be developed I had to go into the same build process eveytime. So I started the idea of packaging everything as RPM, now installing any support modules is a matter of a “dnf install” command; the dependencies are maintained in hardcoded RELEASE files as well as Requires and BuildRequires attributes of the spec file. Recently I finished working on an script that automates building a specific module (not its dependencies; yet) or all RPM packages, this script has been tested on upgrading our EPICS base to 7.0.9 which built every module we have under base 7.0.9. Also I remember an older version of the script was working under base 3.15.8 where we updated asyn and stream device and the RPM packages were re-built because of the update.

 

You can find my work here: https://github.com/AbdallaDalleh/epics-rpm-spec/ , it is not old but a matter of pushing my work to the repo which will be done soon as well as adding more documentation and context. Feedback is highly appreciated.

 

Best Regards,

Abdalla Al-Dalleh

Control Engineer

SESAME

 

From: Tech-talk <tech-talk-bounces@aps.anl.gov> On Behalf Of Ralph Lange via Tech-talk
Sent: Wednesday, October 8, 2025 4:10 PM
To: EPICS Tech Talk <tech-talk@aps.anl.gov>
Subject: Re: Basic EPICS bootstrap (rant)

 

Well,

 

I do understand and share your frustration.

Here's my 2 cts.

 

There is no standard set of modules.

Some are used more widely, some are used less widely, but there is no standard set.

Collections like synApps usually work well for the facility where they are maintained, less well for facilities with similar age, setup and requirements. They often make little sense for facilities that are fundamentally different.

These collections are also inclusive: You will compile and deploy more than you need.

 

There half a dozen different solutions to your problem.

In the last few years, there were multiple workshops at EPICS Collaboration meetings (2019 ff.) about build and deployment options, solutions and frameworks.

The result, if any, is that each of the developers had specific requirements that motivated their specific approach. They're all different and all justified.

The workshop materials are available on the meeting websites. Very valuable.

 

There once were Debian packages.

15 years ago, NSLS-2 spearheaded an effort to maintain Debian packages for many common EPICS modules. That was a lot of effort and basically lasted until the facility switched to RHEL and the resources were withdrawn.

During a few EPICS Collaboration Meetings, the issue was discussed. There was interest, but no one wanted to commit the necessary resources.

 

Everyone needs to pick.

As there is no one-size-fits-all solution, every installation has to pick the approach that fits them best. Read the descriptions and motivations for the existing systems (from the EPICS meeting workshops), compare them to your list of requirements, discuss your options and make a decision.

 

Last not least... As long as you're not using one of the complete solutions:

 

Put RELEASE.local files in the right places.

This Base mechanism allows to keep the module configuration one level above the module directories. A single file keeps the configuration of all modules in your installation, without changes in any of the modules, consistency guaranteed. If you're editing configuration files in many modules, you're doing something wrong.

 

While this is certainly not an easy solution to your problem, I hope it might help find one.

 

Cheers,
~Ralph