RPM & DEB packaging

[ThunderEX]

Hi, I try to add RPM & DEB packaging to close #77. The first commit uses nfpm, which is de facto official packaging tool for golang, to package RPM & DEB. The second commit uses docker image manylinux, which is also de facto official image for python packaging, to build openSeaChest against CentOS 7, so that executable could run on systems with older GLIBC.

There are some points I would like to highlight / may need your input:

1. The second commit is because I find that current meson build are built upon ubuntu 22.04 which has a relative high version of glibc. If you think the second commit is not necessary, I can remove it,
2. For the second commit, I create a new environment of manylinux in strategy matrix, and move publish_release to new environment. The purpose is that, you could still have gcc and clang build with ubuntu-latest to that latest gcc and clang could generate more warnings / lintings etc, but for release artifactory and rpm / deb package, these are built upton manylinux, so that users won't get problem installing them. So sure if this makes sense?
3. For packaging, I noticed that there is a convention that most deb package uses lower case, so I used package name openseachest with all letters in lower case. For installation path, I followed Make\gcc\build_recipes\rpm\OpenSeaChest.spec and the path name is openSeaChest which has first letter in lower case. Please confirm whether these are suitable.
4. For packaging, I fill section of maintainer, vendor, homepage with info from README. Maybe you would like to review these names and email address.
5. For version field of packaging, I put a hard-coded version in nfpm.yaml and add a line of sed script to replace it with tagged version if the workflow is triggered by a git tag. Thus the version could get updated when releasing but stay static in daily build, but recommends a manual bump when release. There is also another approach: use tagged version when tagging and commit hash with daily build, which don't need manual bump but commit hash makes less sense for versioning. What's your opinion?

[vonericsen]

Wow! This is awesome @ThunderEX! Thanks for this pull request.

I've been reviewing it and testing the packages as they are from the second commit. Overall they look great!

For your questions:

1. This is good. Binary compatibility is tricky in Linux and this is the approach we have used for years on internal builds. I think keeping it with CentOS 7 makes sense. CentOS7 is honestly good enough for 98% or more of active linux systems.
2. This makes sense to me. We do the same thing with our internal CI for closed source tools.
3. I think this makes sense for now. We can always change it later. A long time ago I wrote spec and control files for an old tool and put it in /usr/bin but that customer did not like that 😄 so we changed to /opt/ which they liked better. I think that influenced that old spec file in this repo. Unless this project gets other feedback saying to put it somewhere other than /opt/ I think it should stay here for now. If you like /usr/bin better, I would be happy with that too. I think the names and pathnames are good for now too. I know Linux uses most things as lowercase to keep typing simple from the command line. I don't recall our original reason for camelCase at this point...that was too many years ago...maybe even 10 years ago now (this project started as a sample code about 10 years ago).
4. For vendor I think it should be Seagate Technology, for maintainer I think it should be Seagate Technology <opensource@seagate.com>, and homepage I think should be https://www.github.com/Seagate/openSeaChest so that if there is someone looking for source or to file an issue they can bring it here. The main www.seagate.com page doesn't really have a place for that.
5. This is tricky. You have already set it up nicely and in a way that makes some sense to a regular user just wanting a package. Would it be possible for the second approach to use a date & time instead of a commit hash? If that is too complicated that may not be worth it.

[ThunderEX]

Hi @vonericsen I've pushed an update for sections regarding vendor and versioning. For version:

1. I removed the version in meson project, since that one is not of use and need manual bump or some other trick for auto bump,
2. I change hard-coded version to dev so manual build will have such fixed version number,
3. GitHub Actions build triggered by a tag will result in version with tags such as 22.07,
4. GitHub Actions build triggered by other event result in version with date and dev suffix, like 23.01.06-dev. I have the -dev suffix to diff from release version. I have only date but not time because that results in a much longer filename.

Could you please check whether these are fine for you?

[vonericsen]

@ThunderEX, This looks great! I have merged this into develop 😄 Thanks for this great addition to this repo!

[molohov]

Basic question. I have installed the .deb from the latest release, but I don't see any openSeaChest* binaries available on my PATH. Do they have to be manually added?

Version I installed: https://github.com/Seagate/openSeaChest/releases/download/v23.03/openseachest_23.03_amd64.deb

apt-install output (Debian 11):

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'openseachest' instead of './openseachest_23.03_amd64.deb'
The following NEW packages will be installed:
  openseachest
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/3,585 kB of archives.
After this operation, 8,448 kB of additional disk space will be used.
Get:1 /home/molohov/Downloads/openseachest_23.03_amd64.deb openseachest amd64 23.03 [3,585 kB]
Selecting previously unselected package openseachest.
(Reading database ... 146520 files and directories currently installed.)
Preparing to unpack .../openseachest_23.03_amd64.deb ...
Unpacking openseachest (23.03) ...
Setting up openseachest (23.03) ...

[ThunderEX]

@molohov They are installed at /opt/openSeaChest. We had some discussion about install path above so you could take a look.

[vonericsen]

@molohov, We are starting with /opt/openSeaChest for the path, but we can change it to /usr/bin in the future releases. I wanted to see if there was any feedback about this package first since it is new as of this release.

An easy way to temporarily add this to your path is to do export PATH=$PATH:/opt/openSeaChest. This will last until you logout/reboot. There are other ways to append to the path that last across powercycles/reboots like adding this inside the .profile for your user.