Experimental Physics and
Industrial Control System

Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov> · Fri, 24 Feb 2023 18:44:05 -0800

On 2/22/23 02:53, Abdalla Ahmad via Tech-talk wrote:

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 <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.

I do not have a good answer to this.  Understanding the relationship
between dependent modules is hard.  There are tools to analyze some
types of dependencies (eg. abi-diff [1]).  However, this will only
help with the interfaces which the packager (you) know about.  The
sequencer is an appropriate example of a module with many interfaces,
with CLI executable, and custom Make rules.

[1] https://fedoraproject.org/wiki/How_to_check_for_ABI_changes_with_abidiff

When I was evaluating a new module version for epicsdeb, I would
generally look through a diff of the source in addition to any
hints provided with the release in the forms of version numbering,
release notes, etc.

Maybe I am being too pessimistic, but I think that testing and
experience are necessary.  Neither of which are easily scaled up...

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.

As I understand, "Epoch" is intended to be used as a last resort
when an upstream module eg. changes versioning scheme in a way
where a newer version number sorts as less than an older version.

I think you want to use the "Release" field.  This fedora
project page has a good example of how a package version
can evolve.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_examples

When learning about Debian packaging, I spent some time
playing with "dpkg --compare-versions ..." to understand
how version numbers sort in the Debian scheme.  It looks
like "rpmdev-vercmp ..." is an equivalent.

Understanding version sorting is important to understand
when planning how upgrades should proceed.  eg. I think
about this in two "dimensions".  Module version update,
and OS version update, which may happen independently
in either order, or in the same operation.

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?

I am not certain I understand what "group RPMs" means
technically.

When I started epicsdeb, initially I had one giant
package for all of synapps.  Later on this was split
into individual packages.  I am not sure splitting was
an improvement though.  The work involved shifted
around, but preparing and testing updates was still
time consuming one way or the other.

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

Thanks for the links Ralph.

There have been a bunch of things discussed over the last EPICS meetings.

That's very interesting. I'll take a look at them.

Lucas

On Tue, Jan 31, 2023 at 2:27 AM Ralph Lange via Tech-talk <tech-talk at aps.anl.gov <mailto:tech-talk at aps.anl.gov>> wrote:

    The sessions, discussions and workshops at recent EPICS Collaboration Meetings have some more information on this topic.

    2019: https://indico.cern.ch/event/766611/timetable/#20190606.detailed <https://indico.cern.ch/event/766611/timetable/#20190606.detailed>

    2021: https://indico.lightsource.ca/event/2/contributions/27/ <https://indico.lightsource.ca/event/2/contributions/27/>

    2022: https://indico.cern.ch/event/1173788/timetable/#20220920 <https://indico.cern.ch/event/1173788/timetable/#20220920>

    Cheers,
    ~Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System