Almalinux 8 EA4 update?

[sparek-3]

Is it common for AlmaLinux 8 to get separate EA4 updates versus CentOS 7?

Noticed an EA4 update for our AlmaLinux 8 servers, but no such update exists for CentOS 7. Just struck me as being a little strange.

Just to pick one at random:

http://201.159.169.169/cpanelsync/repos/CentOS/8/EA4/x86_64/ea-apache24-mod_expires-2.4.54-2.3.3.cpanel.x86_64.rpm

exists for AlmaLinux 8 (CentOS 8?)

But the latest version for CentOS 7 is:

http://201.159.169.169/cpanelsync/repos/CentOS/7/EA4/x86_64/ea-apache24-mod_expires-2.4.54-2.3.2.cpanel.x86_64.rpm

I don't see any mention of an EA4 update in the Changelogs either:

EasyApache 4 Change Log 2022 | cPanel & WHM Documentation

EasyApache 4 does not use versioning and organizes changes by date only.

docs.cpanel.net

Just seems odd to me, but maybe it's expected behavior.

 

[cPRex]

Hey there! I spoke with the EasyApache team and they let me know that any numbers after "2.4.54-2" are irrelevant as those just get assigned by the open build service and aren't actually related to any particular changes in the package. "-2" is the end of the actual "version" of the software as far as changes are concerned.

 

[sparek-3]

That kind of begs the question... why were the packages repackaged as an update?

That... just seems weird. Left hand not knowing what the right hand is doing?

I do note that the files:

http://201.159.169.169/cpanelsync/repos/CentOS/8/EA4/x86_64/ea-apache24-mod_expires-2.4.54-2.3.3.cpanel.x86_64.rpm - md5sum: a4a82158162c626091ea1401647d5a46
http://201.159.169.169/cpanelsync/repos/CentOS/8/EA4/x86_64/ea-apache24-mod_expires-2.4.54-2.3.2.cpanel.x86_64.rpm - md5sum: 9a420c7f0ee8ad1e3e2a5c103e2540d2

have different md5sums.

I'm not doubting that the packages are effectively the same. But why were they repackaged. It looks like the whole EA4 system on AlmaLinux 8 was repackaged (or at least has updates).

2.4.54-2.3.2 to 2.4.54-2.3.3 may not mean any changes (which... that doesn't really sound right either) but it's going to trigger a system update when this is changed.

Really seems odd that nobody's concerned about packages just seemingly repackaging themselves. Has someone been feeding the mogwais after midnight?

 

[cPRex]

It's not so much that we don't know, but that the processes are just different for the different OS builds. For example, those two operating systems will have different dependencies due to things like ea-openssl, which doesn't exist for Cent8/Alma/Ubuntu.

 

[cPanelCory]

That kind of begs the question... why were the packages repackaged as an update?

That... just seems weird. Left hand not knowing what the right hand is doing?

I do note that the files:

http://201.159.169.169/cpanelsync/repos/CentOS/8/EA4/x86_64/ea-apache24-mod_expires-2.4.54-2.3.3.cpanel.x86_64.rpm - md5sum: a4a82158162c626091ea1401647d5a46
http://201.159.169.169/cpanelsync/repos/CentOS/8/EA4/x86_64/ea-apache24-mod_expires-2.4.54-2.3.2.cpanel.x86_64.rpm - md5sum: 9a420c7f0ee8ad1e3e2a5c103e2540d2

have different md5sums.

I'm not doubting that the packages are effectively the same. But why were they repackaged. It looks like the whole EA4 system on AlmaLinux 8 was repackaged (or at least has updates).

2.4.54-2.3.2 to 2.4.54-2.3.3 may not mean any changes (which... that doesn't really sound right either) but it's going to trigger a system update when this is changed.

Really seems odd that nobody's concerned about packages just seemingly repackaging themselves. Has someone been feeding the mogwais after midnight?

Hello,

These are artifacts of our build process using the Open Builds System from OpenSUSE. As such, in this case, other files were updated which triggered a rebuild of the entire stack for CentOS8 (and therefore Alma8). This is not unusual and if you look at the history this happens more often than not. I am the left hand and the right hand so this falls on me and I assure you we are aware that this happens

There are often times we have to make changes to the build system configurations themselves, which can cause a rebuild of certain repositories, as well as a slew of other issues and processes that have nothing to do with the packages changing at all, but simply they are rebuilt. This of course will give them a new md5sum as you noted, but if you check out the github you can see that nothing in ea-apache2 was changed in the source: GitHub - CpanelInc/ea-apache2 at production

I understand your concern but as Rex stated, everything after 2.4.54-2 is done by any possible changes to the OBS build system, which at times can rebuild the entire stack. It happens on CentOS8 more often because we have more packages moving around there than on CentOS7 and CentOS6, however they do happen there as well.

I hope the addresses your concerns and if not please let me know and I'll try to answer any further questions.

Thanks!

 

[sparek-3]

There are often times we have to make changes to the build system configurations themselves, which can cause a rebuild of certain repositories, as well as a slew of other issues and processes that have nothing to do with the packages changing at all, but simply they are rebuilt. This of course will give them a new md5sum as you noted, but if you check out the github you can see that nothing in ea-apache2 was changed in the source: GitHub - CpanelInc/ea-apache2 at production

I think this hits it.

I could understand all of the packages being rebuilt or repackaged, but I assumed that would be because of a change in something else. An update to something in core Apache would trigger all of the Apache modules to be rebuilt. It wasn't so much that mod_expires package had been repackaged, it was more of a "what changed that triggered all of these to be repackaged?" and nothing was noted in the Changelog.

I guess just changing a period in a comment in the configurations can trigger a full repackage. I had not considered something like that.

 

[cPanelCory]

I think this hits it.

I could understand all of the packages being rebuilt or repackaged, but I assumed that would be because of a change in something else. An update to something in core Apache would trigger all of the Apache modules to be rebuilt. It wasn't so much that mod_expires package had been repackaged, it was more of a "what changed that triggered all of these to be repackaged?" and nothing was noted in the Changelog.

I guess just changing a period in a comment in the configurations can trigger a full repackage. I had not considered something like that.

Exactly, and even further, if we change Project Configurations to accommodate a new setting, that can trigger a full stack rebuild. There are also cascading dependencies that will trigger rebuilds, such as Rex noted, if ea-openssl11 updates, we use it in most of the EA4 stack for CentOS6/7, so many of the 130 or so packages would rebuild. It is just the nature of this particular build system we use.