Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Sun, 25 Apr 2021 10:22:10 -0700

On 4/25/21 2:08 AM, Abdalla Ahmad wrote:
> Hello Michael
> 
> In your spec file can you please explain in more details what's going on in line 76? I have seen these definitions before I just don't recall what they are for.

I take it you mean this monster.

> make -C "%{_builddir}/%{?buildsubdir}" %{?_smp_mflags} \
> LINKER_USE_RPATH=NO \

Skips passing -rpath when linking.  Distribution policies usually discourage
absolute rpath entries for binaries which are already in the default search path.
eg. by adding files under /etc/ld.so.conf.d/

This might be revisited now that LINKER_USE_RPATH=ORIGIN is an option if it
where desirable to allow RPMs to be "relocatable".

> SHRLIB_VERSION=%{version} \

This is overriding the library SONAME to be the RPM version, which in this instance
is exactly the same.  When packaging of binaries more attention needs to be paid to
ABI (in)compatibility.  SONAME is how this is expressed.

> INSTALL_LOCATION="%{buildroot}%{epics_prefix}" \

Where "make install" will actually place files.

> FINAL_LOCATION=%{epics_prefix} \

Compiled in paths will reference the location where RPM will ultimately place things.
eg. softIoc builds in "%{epics_prefix}/dbd/softIoc.dbd".

Again, less necessary now that epicsGetExecDir() allows softIoc to use
a relative path "../../dbd/softIoc.dbd".

> BIN_PERMISSIONS=755 \
> LIB_PERMISSIONS=644 \
> SHRLIB_PERMISSIONS=755

Some of the helper utilities run during the RPM build process are picky about
file permissions.  The two I recall are binaries needing to be owner writable,
and shared libraries needing to be executable.

I don't recall whether doing otherwise resulted in a hard error.  It may have
been something more subtle, like an incomplete dependency list if the shared
libraries aren't scanned.

> Best Regards,
> Abdalla.
> 
> -----Original Message-----
> From: Tech-talk <tech-talk-bounces at aps.anl.gov> On Behalf Of Michael Davidsaver via Tech-talk
> Sent: Thursday, April 22, 2021 6:07 PM
> To: Ralph Lange <ralph.lange at gmx.de>; Hu, Yong <yhu at bnl.gov>
> Cc: EPICS Tech Talk <tech-talk at aps.anl.gov>
> Subject: Re: RPM packages for EPICS
> 
> On 4/22/21 12:55 AM, Ralph Lange via Tech-talk wrote:
>> On Wed, 21 Apr 2021 at 17:36, Johnson, Andrew N. via Tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:
>>
>>     On Apr 21, 2021, at 9:43 AM, Hu, Yong <yhu at bnl.gov <mailto:yhu at bnl.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!
>>
>>     ITER has been building RPMs for all their software including EPICS modules on RHEL for many years, but I don’t believe they are allowed to share the results with the community for intellectual property reasons (administrative and legal, not for any technical reasons).
>>
>>
>> IP issues are just a small aspect of this...
>> Let me iterate (we have been presenting this at collaboration meetings).
>>
>> The ITER controls division builds and distributes CODAC Core System (CCS), a RHEL based Linux distribution for all control system developments in the context of the ITER project. All CCS software is packaged as RPMs.
>>
>> However, all CCS software modules are built using Maven. RPM packaging is done "under the hood" by a proprietary Maven ITER plugin, as a part of Maven's "package" goal, using the results of the Maven "compile" goal. Most CCS RPMs do not install in the standard RHEL system locations, but into a structure below '/opt/codac', the EPICS parts keeping the original non-standard directory structure.
>>
>> If you are linked to the ITER project, you can register to become a CODAC Core System user and use the complete ecosystem.
>> Installing CCS RPMs on a standard RHEL system is technically possible, but as they are not generated in a standard way, do not follow all applicable Fedora / Red Hat guidelines, install in non-standard locations and often require other CCS packages, they are of very limited use outside CCS.
> 
> A relevant thread started by Abdalla Ahmad, who was/is building RPMs.
> 
> https://epics.anl.gov/tech-talk/2018/msg02078.php
> 
> 
> In 2019 I did a proof of concept for an Osprey customer of packaging Base according to (as I understood them) the Fedora packaging rules.
> So far it has not gone any further.
> 
> https://github.com/mdavidsaver/epics-base/blob/spec/epics-base.spec
> 
> I also explored the excellent Fedora COPR package building and hosting service.
> 
> https://copr.fedorainfracloud.org/coprs/mdavidsaver/epics-base/packages/
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System