RE: Packaging EPICS and support modules as RPM

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

Hi Michael

Thank you very much. That was really helpful. I agree too with separating sets of packages for each base version.

I have 2 questions in return:
1. The base build recipe you mentioned, is it how you do it on Debian systems or is it how EPICS build system behave?
2. Regarding your rant :D , What version should I put for my RPM for EPICS base 3.15.6? Doesn't having 3.15.6 as the package version make sense? I mean I have installed a package called epics-base and its version is 3.15.6

Best Regards,
Abdalla.

-----Original Message-----
From: Michael Davidsaver [mailto:mdavidsaver@gmail.com] 
Sent: Sunday, November 25, 2018 7:38 PM
To: Abdalla Ahmad <abdalla.ahmad@sesame.org.jo>
Cc: tech-talk@aps.anl.gov
Subject: Re: Packaging EPICS and support modules as RPM

On 11/22/18 1:07 AM, Abdalla Ahmad via Tech-talk wrote:
...
> Anything that depends on EPICS base must have its EPICS_BASE defined in the configure/RELEASE file, and since there are more than one major version of EPICS, some might try base 3.14, 3.15 or 3.16 or even 7. In order for the RPM spec file to work properly, EPICS_BASE must be hardcoded in configure/RELEASE. So the question is, does it make since to create separate repo for each base version and each repo contains all support modules built against the corresponding base version? What we think of right now is 4 repos: base 3.14, base 3.15, base 3.16 and base 7. What do you think of this approach?

Having answered some of the "how" of epicsdeb, I'll talk about the "why".

From the Debian side, the questions start with:

1. Why not install everything under /usr?  eg. /usr/include/cadef.h

One of my early realizations was that there will always be a desire to preserve the possibility to ignore the system packages and build/run Base under /home.  It might be to test/workaround a bug, or to use features from newer releases, or because some users want to be "self sufficient".

To ensure this is preserved, I decided to avoid installing anything in the default build time search paths.

2. Why /usr/lib/epics ?

This is a place where Debian policy allows a more or less arbitrary tree, which deflects most of the criticism that the Base install layout doesn't follow the usual *NIX conventions.  This avoids more invasive Makefile changes in Base, and any downstream modules with custom install rules (eg. for .ui files).


From the EPICS side, the questions start with:

3. Why not separate /usr/lib/epics/base, /usr/lib/epics/asyn, ... ?

This separation means extra work in managing configure/RELEASE in downstream modules.  For me then, the question isn't why to combine, but rather why to separate?

The package manager keeps track of which file came from which package.
So uninstall is always clean, and any name collisions would be prevented during the package install phase.


4. Why not /usr/lib/epics/3.15.1/... ?

That is, why only allow a single Base version to be installed?
The question usually coming from experience with NFS "installs".

With a package manager, in addition to the packages themselves it is necessary to consider the package repository.  Or rather, repositories.
It will be normal to have separate, and self consistent, sets of packages for different combinations of modules versions.

With Debian, use of /usr/lib/epics creates the restriction that at any given time, each computer can have packages from only one repository (really from one self consistent set).


That said, the main reason I didn't do this is a technical limitation of Debian packages, which may not exist (anymore) with RPM.

To accomplish side-by-side install would require different package names.
eg. instead of "epics-dev" having "epics3.15.1-dev" and "epics3.16.2-dev".

The mechanics of deb packages make it very difficult to compute binary package names.  So to go this route would have meant a lot of tedious manual changes to packaging files.

In practice at NSLS2 this wasn't a major restriction.
Computers weren't upgraded all at once, and existing management tools know how to handle switching Apt repositories.


Also, as I minor rant.  Your collection of specific package versions is a distribution.
Please don't use a Base version as a distribution version!  There is a reason that eg. Debian 8.0.1 isn't numbered 2.24 (the glibc version).