Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Distro packaging for SMFC #34

Open
emansom opened this issue Apr 3, 2024 · 17 comments
Open

Distro packaging for SMFC #34

emansom opened this issue Apr 3, 2024 · 17 comments
Labels
enhancement New feature or request

Comments

@emansom
Copy link
Contributor

emansom commented Apr 3, 2024

I'm in the process of creating an .spec file here to be used in conjunction with tito for RPM release management.

This will allow publishing to Copr for easy package testing (currently testing here), and eventual upstreaming to EPEL for wider package availability to the EL community at large.

Once the .spec file conforms to all Fedora and EL packaging rules, i'll open up a PR here to merge it in.

However, one of the hurdles I ran into with SMFC while testing on EL: is that the default kernel that ships with RHEL 9, Rocky Linux 9 and CentOS Stream 9 does not have the drivetemp kernel module built-in. This can be worked around with hddtemp to success, but it should not be broken on package installation.

Further the requirement to modify the hd_names variable first before it's functional is tedious and further complicates a functional state from the get go.

It would help the out-of-the-box experience for EL users to have SMFC automatically discover HDDs when e.g. hd_names is set to auto and to have SMFC fall-back/default to hddtemp for temperature.

@petersulyok
Copy link
Owner

Hi @emansom, sounds great. What is the kernel version you work with at RHEL?

@emansom
Copy link
Contributor Author

emansom commented Apr 10, 2024

Hi @emansom, sounds great. What is the kernel version you work with at RHEL?

Currently don't have access to any RHEL 9 boxes to verify, however: Rocky Linux 9 ships with kernel version 5.14.0-362.24.1.el9_3.0.1.x86_64 as of now.

Given Rocky Linux 9 and RHEL 9 are using the same SRPMs and remain bug-for-bug compatible, I presume it's the same kernel build config and version on RHEL 9.

For a detection algorithm I think simply checking if the paths to the drive hwmon files exists would suffice, this would handle all cases where:

  1. drivetemp kernel module is not loaded
  2. drivetemp kernel module is not available
  3. drivetemp kernel module is built-in and doesn't show up in e.g. lsmod but is functional
  4. drivetemp kernel module is available and loaded

@emansom
Copy link
Contributor Author

emansom commented Apr 10, 2024

Fedora package review requested:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2274274

@emansom
Copy link
Contributor Author

emansom commented Apr 10, 2024

Related PR #35 opened

@petersulyok petersulyok added the enhancement New feature or request label Apr 13, 2024
@petersulyok
Copy link
Owner

petersulyok commented Apr 13, 2024

Hi @emansom,

The effort you put into this is really impressive, thanks for that.
I have several questions and comments:

  1. Recently, I've implemented the checking of run-time dependencies and which is contradicting this feature request (e.g. if drivertemp is not loaded then smfc will be stopped)
  2. In my mind this feature could be turned on and off with a command-line parameter (e.g. -A)
  3. file src/smfc.preset: could it be in .tito folder?
  4. In the future I would like to collect all packaging related artifacts in a folder but not sure if it is feasible.
smfc
    >src
    >packaging
        >deb
        >rpm       
        >.tito
        >arch
    >test

Would it be possible with tito?

Currently there is an issue with codecov plugin in GitHub workflow (it uploads the coverage result to codecov.io), this is the reason why the merge failed. I try to come up with an implementation soon.
Cheers,

Peter

@petersulyok
Copy link
Owner

One additional comment that .tito/packages/smfc file contains a version number. It is getting harder and harder to track all of the instances of the version numbers. Would it be possible to generate this or make it automated somehow?

I'm also thinking on a central version number and central updater solution.

@emansom emansom changed the title Automatic HDD discovery and failover to hddtemp Distro packaging for SMFC Apr 13, 2024
@emansom
Copy link
Contributor Author

emansom commented Apr 13, 2024

  1. In my mind this feature could be turned on and off with a command-line parameter (e.g. -A)

And that command-line parameter can then be passed via /etc/default/smfc. Yes, workable solution 🙂

  1. file src/smfc.preset: could it be in .tito folder?

.tito is managed by the tool itself, best not to touch it unless required. I've moved the systemd preset and unit files to their own directory in #36.

  1. In the future I would like to collect all packaging related artifacts in a folder but not sure if it is feasible.
smfc
    >src
    >packaging
        >deb
        >rpm       
        >.tito
        >arch
    >test

Would it be possible with tito?

Probably not. I will dig thru the documentation to see if paths can be changed.

@emansom
Copy link
Contributor Author

emansom commented Apr 13, 2024

Opened #36 to address feedback from Fedora packager.

@emansom
Copy link
Contributor Author

emansom commented Apr 13, 2024

One additional comment that .tito/packages/smfc file contains a version number. It is getting harder and harder to track all of the instances of the version numbers. Would it be possible to generate this or make it automated somehow?

Fedora packager @NeilHanlon mentioned rpmautospec which may be able to automate this.

I'm also thinking on a central version number and central updater solution.

Setting up an Open Build Service instance could be a solution, combined with a CI/CD tool that integrates with multiple distro/OS-specific packaging definition files would ease this.

I currently lack sufficient resources for this, so only AUR, PPA and Copr (Fedora repo and EPEL in the future) would be feasible from my end for the time being.

@emansom
Copy link
Contributor Author

emansom commented Apr 14, 2024

A way to generate man pages automatically is also needed per the guidelines, as smfc is a binary.

Update: found this project: argparse-manpage.

It fits the need, but does requires some code modification: namely a static get_parser() method added that returns smfc's argparse.ArgumentParser instance.

@NeilHanlon
Copy link

NeilHanlon commented Apr 17, 2024

Heya folks! Happy to help on this. I think it would be really helpful for the Fedora Server Working group, and of course for RHEL systems as well.

Have you looked into using packit, perhaps? This can take care of a lot of the "dirty" work in Fedora packaging--including and especially things like version bumps, etc

@NeilHanlon
Copy link

A way to generate man pages automatically is also needed per the guidelines, as smfc is a binary.

fwiw, this is not a strict requirement for the manpages to be automatically generated; though of course having them be as up-to-date as possible would be beneficial (and is why the policy says maintainers should work with upstream and use those manpages where available)

@petersulyok
Copy link
Owner

Hi @NeilHanlon, welcome.
I do not have any preference on packaging or tools. My purpose here is to keep the changes on a reasonable and safe level.

@petersulyok
Copy link
Owner

Hi @emansom, I see you tried to convert smfc to a Python package, but I do not see the reason / benefit. Please explain your motivation.
Till now I tried to keep smfc as simple as possible, since it does not have any Python dependency.
If smfc was a Python package:

  • it would be uploaded to pypi.org
  • it would be installed using pip (note: pip installation to OS level is not recommended nowadays, less and less distros are supporting this)

I have done this in another repo: https://github.com/petersulyok/diskinfo

@emansom
Copy link
Contributor Author

emansom commented Apr 20, 2024

Hi @emansom, I see you tried to convert smfc to a Python package, but I do not see the reason / benefit. Please explain your motivation.

This was done for the tests to run successfully in the RPM package chroot. Fedora's Python RPM package macros make some assumptions about the Python environment and requires it to be exposed as a package by pyproject for the smfc namespace/package to be available when the tests are invoked.

Till now I tried to keep smfc as simple as possible, since it does not have any Python dependency.

It does not add any extra runtime dependencies, only during the RPM package building and package testing phases are the extra tooling (setuptools, pyproject, pytest) required.

If smfc was a Python package:

  • it would be uploaded to pypi.org

Good catch. I read over this part in the guidelines. Yes, this is required to mitigate security concerns: where a novice user might be tricked into sudo pip install smfc. If the smfc package there isn't controlled by the same author, they might install malware accidentally.

This will require some modification to the RPM definition file (smfc.spec) to fetch from PyPi instead, as well as some extra tooling (GitHub action) to be added to publish to PyPi on new release.

  • it would be installed using pip (note: pip installation to OS level is not recommended nowadays, less and less distros are supporting this)

This is the job of Fedora's Python RPM package build macros (and deb equivalent in the future), it invokes setuptools (via pyproject) to install it to OS level at site-packages within a chroot environment which then gets "zipped up" to a final RPM file.

This RPM file can then be distributed across distro repositories, making it end user installable via dnf install smfc.

@petersulyok
Copy link
Owner

I've got an idea how could we divide the tasks and step further in RPM packaging. Since the Python packaging is fundamental and it effects everything (including installation and unit testing etc.), I would do that.
You may create a docker file (with one or more a selected distros, required packages for build creation etc.) for the RPM package creation. In this way anybody would be able to check if RPM packaging is working properly.

@petersulyok
Copy link
Owner

Hi @emansom and @NeilHanlon,

I just finished the smfc python packaging and I'm ready to upload it to pypi. I would like to hear your opinion on how tito can:

  • install a pypi package at installation time in side a rpm package
  • resolve the pypi package dependencies here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants