search

rabbitmq / erlang-rpm

Latest Erlang/OTP releases packaged as a zero dependency RPM, just enough for running RabbitMQ
https://rabbitmq.com/install-rpm.html
Other
545 stars 117 forks source link

Upgrade to 26.2.5.2 #126

Closed tubatodd closed 2 months ago

tubatodd commented 2 months ago

Is your feature request related to a problem? Please describe.

This bug was reported upstream to erlang/otp on my behalf a couple months ago. https://github.com/erlang/otp/issues/8482

It has been been merged into 26.2.5.1 and was released a few weeks ago. Since then 26.2.5.2 is now available. I would like to see this erlang-rpm project updated to 26.2.5.2

Describe the solution you'd like

Upgrade to 26.2.5.2

Describe alternatives you've considered

No response

Additional context

No response

michaelklishin commented 2 months ago

I cannot promise any ETA, we are forced to move infrastructure, including the pipelines that produce the x86-64 versions of this RPM.

This is open source software, so anyone can bump the version and build it on an x86-64 or an aarch64 architecture in Docker.

michaelklishin commented 2 months ago

The x86-64 part was moved to Actions at least in part. I have bumped the version, now let's see.

aarch64 packages are built locally once we have a GitHub release to publish them to.

tubatodd commented 2 months ago

@michaelklishin it appears that there is a newly published set of 26.2.5.2 artifacts under releases.

Edit:

I will be needing el8 packages. Will those be published as well?

tubatodd commented 2 months ago

Thank you for looking into this so quickly.

michaelklishin commented 2 months ago

@tubatodd just in case you need them, aarch64 versions of the package are now also available from the GitHub release, and our Cloudsmith mirrors have been synced to provide 26.2.5.2.

tubatodd commented 2 months ago

@michaelklishin what is the status of el8 packages? I noticed the source.zip code makes no mention of el8 where as the previous 26.2.5 provided that package option (and el7)?

michaelklishin commented 2 months ago

@tubatodd looks like they are no longer produced starting with the move to Actions. As for CentOS 7 packages, CentOS 7 has been dead for several years now.

michaelklishin commented 2 months ago

I now see why CentOS 8 packages are not built: mirrorlist.centos.org no longer resolves.

The solution requires modifying the image and the certificates that CentOS 8 bundles seemingly will cease to work soon (or already have).

tubatodd commented 2 months ago

@michaelklishin so we are running RHEL 8 and that is what we need el8 packages for. Other clones like Alma 8.x and Rocky 8.x would also make use of el8 packages. So are you saying el8 is no longer going to be supported with this dot release? The rabbitmq packages are (or were) still being built for el8. This is a major blocker for us and I imagine anyone using RHEL8, Alma 8 or Rocky 8.

tubatodd commented 2 months ago

I now see why CentOS 8 packages are not built: mirrorlist.centos.org no longer resolves.

The solution requires modifying the image and the certificates that CentOS 8 bundles seemingly will cease to work soon (or already have).

With CentOS 8 no longer being a thing, the logical next step most people are doing is moving to Rocky 8. Rocky was created by the same person who started CentOS back in the day.

michaelklishin commented 2 months ago

@tubatodd I'm afraid you are asking for a bit too much. CentOS 8 is dead according to CentOS maintainers. Why should Team RabbitMQ maintain packages for a distribution whose repositories have been taken offline?

tubatodd commented 2 months ago

@tubatodd I'm afraid you are asking for a bit too much. CentOS 8 is dead according to CentOS maintainers. Why should Team RabbitMQ maintain packages for a distribution whose repositories have been taken offline?

@michaelklishin please see my comments above. I am not wanting CentOS 8. RHEL8, Alma 8 and Rocky 8 are still very much alive.

michaelklishin commented 2 months ago

I still don't see why our small team should spend time worrying about Alma Linux 8 or Rocky Linux 8.

RHEL 8, CentOS 8 is a distribution from 2019, and CentOS 7 is a distribution from 2013. We do not support other distributions when they reach the fifth year, and we certainly do not support 10+ year old distributions.

Updating CentOS 8 image to use vault.centos.org was enough to get the el8 version to build.

If it requires more work than that, we will drop el8 support entirely. The source of this package is available to anyone who needs to build it. Even for CentOS 7 on x86-64, which still has a separate branch and all it takes to build it is a functional image plus

cd docker
./build-packages.sh
ls -l ./all_rpms
michaelklishin commented 2 months ago

The el8 workflow has [finished successfully]() and the release was updated.

I will try to switch it to use a Rocky Linux 8 image. If it requires more than an hour to migrate, we will drop el8 support. We are not Rocky Linux maintainers and never intended to be.

Packaging software for old distributions is a responsibility of its users or maintainers (or maintainers of a fork such as Rocky Linux or Alma Linux).

michaelklishin commented 2 months ago

Mirrors have been re-synced again to include the el8 package.

A Rocky Linux 8-based image builds successfully. Building the RPM on it and testing the result is for another day.

tubatodd commented 2 months ago

I still don't see why our small team should spend time worrying about Alma Linux 8 or Rocky Linux 8.

RHEL 8, CentOS 8 is a distribution from 2019, and CentOS 7 is a distribution from 2013. We do not support other distributions when they reach the fifth year, and we certainly do not support 10+ year old distributions.

Updating CentOS 8 image to use vault.centos.org was enough to get the el8 version to build.

If it requires more work than that, we will drop el8 support entirely. The source of this package is available to anyone who needs to build it. Even for CentOS 7 on x86-64, which still has a separate branch and all it takes to build it is a functional image plus

cd docker
./build-packages.sh
ls -l ./all_rpms

The main reason I feel that el8 support should still be provided, is because Redhat Enterprise Linux 8 (RHEL8) commercial Linux OS is still supported through 2029 and there are various large companies, including mine, that are utilizing it for the time being.

It may seem like I am making this request specifically for my company, but I am really just highlighting the fact that RHEL8 is still a fairly widely used and commercially supported version.

And for the record, I am using this situation to pitch to our upper management to migrate to RHEL9 .

tubatodd commented 2 months ago

Mirrors have been re-synced again to include the el8 package.

A Rocky Linux 8-based image builds successfully. Building the RPM on it and testing the result is for another day.

@michaelklishin on behalf of my entire engineering team, we would like to thank you for providing this build. As I stated above, I will leverage this scenario to push forward our migration to RHEL9 in the future.

michaelklishin commented 2 months ago

@tubatodd thank you for educating me about Rocky Linux 8. The aarch64 el8 packages of this release were produced on Rocky Linux 8 (locally) and it seems to work perfectly fine 👏

michaelklishin commented 2 months ago

As for Red Hat supporting their distribution through 2029, it might as well be 2059, they do not share any of that extended support revenue with OSS maintainers, so it's up to them to deliver on their unrealistically long support schedule promises.

By 2029, OpenSSL/LibreSSL might bump a couple of majors and many tools (such as Erlang) will adopt the most recent one, leaving a lot of older distributions behind. We have seen exactly that happen to CentOS 7 with OpenSSL 3.x.