Re: EPICS deb/rpm packaging

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

Hi Lucas, All

> Is FRIB still using https://github.com/epicsdeb?

FRIB is using our own internal CI/CD system for building and deploying Debian packages.

 

I'm not building and maintaining EPICS software, but I do build and deploy a lot of other controls-related software, I'd like to share my point of view on your question:

 

1. Push to upstream means additional effort and probably quality of assurance is required;

2. Each lab/institute usually has site-specific requirements, software configurations, etc. which may still be effort-required to patch the upstream packages before using them;

3. Sometimes, it is more flexible to just maintain the homemade software.

Thanks,

Tong 

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Lucas Russo via Tech-talk <tech-talk at aps.anl.gov>
Sent: Monday, January 30, 2023 5:59:29 PM
To: Abdalla Ahmad
Cc: tech-talk at aps.anl.gov
Subject: Re: EPICS deb/rpm packaging

 

[EXTERNAL] This email originated from outside of FRIB

Hi Abdalla,

That's awesome. I'm more familiar with Debian, but ALS/ALS-U are RHEL based too. So, that could be interesting

for us, for sure.

I feel so much effort has been put to packaging EPICS (by many different people and labs, with exciting results) 

that I wanted to better understand the "last" remaining step into pushing that upstream.

Now with NSLS-II transitioning to RHEL, I wonder which labs are still using this: https://github.com/epicsdeb

And also, I imagine the NSLS-II Debian repo (https://epicsdeb.bnl.gov/debian/) is gonna become 

unsupported/unmaintained, but can anyone from NSLS-II vouch for that?

Is FRIB still using https://github.com/epicsdeb?

Thanks!

Lucas

On Wed, Jan 25, 2023 at 10:55 PM Abdalla Ahmad <Abdalla.Ahmad at sesame.org.jo> wrote:

Hello Lucas

 

I own the 2^nd repository J. For me I always had the idea of creating an online repo hosted here at SESAME but never got the time to work on it, but for now, all of our machine and beamlines IOCs are running using these RPMs, the setup is even working perfectly for Rocky Linux 8. To help automate building and publishing RPMs, I wrote two scripts (fetch.sh and build.sh) which fetch latest version of all modules, build and package them as RPMs, so I think that would be a good starting point. For us we will continue working internally on RPM packaging especially as we are migrating to Rocky Linux 8, but if there is really an interest in pushing this work further to official repositories, we are more than interested to collaborate.

 

I plan to re-build all RPMs because more servers and PCs have been migrated to Rocky Linux, once I finish I will share my results here for anyone interested.

 

Best Regards,

Abdalla.

 

From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Lucas Russo via Tech-talk
Sent: Wednesday, January 25, 2023 1:24 AM
To: EPICS Tech Talk <tech-talk at aps.anl.gov>
Subject: EPICS deb/rpm packaging

 

Hello everyone,

 

I know this has been a subject of discussion many times, but I wanted to bring this up one more time.

 

I know some people have started efforts to package EPICS components in a .deb and .rpm a few times. Some examples:

 

*) https://github.com/epicsdeb

*) https://github.com/AbdallaDalleh/epics-rpm-spec

 

And there are possibly many others

 

What is preventing us from pushing this effort upstream? To official debian/centos repositories.

 

And what can we, as a community, do to help that, if that is of interest to labs.

 

Thanks!

 

Lucas