Re: RPM packages for EPICS

["Hu, Yong via Tech-talk" <tech-talk at aps.anl.gov>]

Thanks, Ralph. That is really good advice!

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Reply-To: Ralph Lange <ralph.lange at gmx.de>
Date: Thursday, April 22, 2021 at 5:18 AM
To: "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov>
Subject: Re: RPM packages for EPICS

 

On Wed, 21 Apr 2021 at 16:43, Hu, Yong via Tech-talk <tech-talk at aps.anl.gov> wrote:

Has any facility built, smoothly deployed and happily used RPM packages for EPICS installation of the base and popular support modules (seq, asyn, motor, streamDevice, etc.)? Please share your repositories (or building rules / specs) and your experience. Thank you!

 

My 2cts...

 

The Debian packaging is "near distribution quality": following all applicable guidelines and file system standards, including all necessary legal and license information. The packages would need few changes (if any) to be accepted in the Debian distribution.

While the packaging tools are different, Fedora / Red Hat guidelines and rules are very similar.

 

I think it would be best to keep a Red Hat packaging effort as close as possible to the Debian packaging, using the same names, versions, places, techniques. With the Debian packaging and its helper tools as a reference, the way towards a similar Red Hat packaging should be straightforward. Long term, it would make it easier to apply fixes for problems found on one distribution to the other, improve user experience (packaged EPICS works the same on Debian and RedHat) and hopefully create a larger group of packaging contributors, which could/should reduce the amount of work for each person. A lot of EPICS places use Red Hat, so I am sure there are others who would help.

 

My suggestion would be to start working on Red Hat packaging within the epicsdeb project on GitHub that collects the existing Debian packaging. (If the "deb" part of the name becomes an issue, we could rename it at some point.)

Create a workflow / branching model that allows for both packaging efforts to use the same sources and add their specifics without affecting the other.

 

Cheers,
~Ralph