Upstreaming RPM packaging into CI process

[ChrisDryden]

Was hoping to see what the maintainers think of the idea of adding some of the RPM packaging scripts directly into the repo and building them in the CI process in main branch builds? As a high level implementation something like this, where the base .spec files are in the repo to make adopting and maintainability of these distro's much easier across many systems:

jobs:
  build-rpm:
    runs-on: ubuntu-latest
    container:
      image: amazonlinux:2023
...
      - name: Build RPM
        run: |
          rpmbuild -ba uutils-coreutils.spec

I am working on getting the ball rolling on adoption of uutils coreutils into the main distro's for RHEL AL2/AL2023 and beyond as an alternative and possibly as a default for future releases. I'm not the most familiar with this process but my understanding is that to have the ability to install uutils-coreutils by default on these distros requires an internal advocate and team at Redhat or Amazon to take ownership on support like CVE's and that they both are downstream from the Debian rawhide release which comes from here: https://src.fedoraproject.org/rpms/rust-coreutils . It also seems like a self perpetuating cycle where that once the rpm is available and adopted then those organizations provide more funding and support to improve the library. It's visible to me that the interest is there, its just a barrier to entry for having to keep up to date with all of the patches and compatibility on a project that is changes so much on the day to day.

I was taking a look at the Ubuntu patches https://git.launchpad.net/~juliank/ubuntu/+source/rust-coreutils/log/debian/patches?h=ubuntu/devel and the Debian rawhide patches https://src.fedoraproject.org/rpms/rust-coreutils/tree/rawhide and I'm thinking that it would be much easier in general if we had the indication of which changes would cause issues with the different distributions when they are made and fix them upstream so that its as easy as doing a sync whenever these distributions want to release the latest changes.

Taking for example my stty changes, I'm under the assumption that one of the reasons its difficult to merge my PR's for stty fixes is that there are currently patches in stty related to the glibc issue, but if I had the ability to run this in the CI, I could easily just adjust that patch as part of the CI as a reference. Was hoping I could get @oech3 's thoughts too since you appear to be involved in the patching for ubuntu side if this would be beneficial?

[oech3]

https://github.com/uutils/coreutils/issues/9172

they are useless duplications

I think current musl binary and /usr/local/bin is enough (and maintaining all distro specific pkgs at here is impossible).

[oech3]

But do we want to have runner image with newest glibc for security at least for?: https://github.com/actions/runner-images