CentOS - Jan 2021 - CentOS Stream suitability as a production webserver

Le 06/01/2021 ? 08:06, Gordon Messmer a ?crit?:
> Are you describing an actual problem, right now, or is that an invented
example?
No, this was an actual problem I had back in April 2020. Upgrading from CR
broke imagemagick, so I couldn't use the corresponding PHP modules, so my
Roundcube installation was broken for a few weeks.

One of the things I like about Oracle Linux is that they maintain their own
EPEL repo, most probably to prevent these things from happening.

-- 
Microlinux - Solutions informatiques durables
7, place de l'?glise - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : info at microlinux.fr
T?l. : 04 66 63 10 32
Mob. : 06 51 80 12 12

On Wed, Jan 06, 2021 at 08:31:34AM +0100, Nicolas Kovacs
wrote:
> 
> No, this was an actual problem I had back in April 2020. Upgrading from CR
> broke imagemagick, so I couldn't use the corresponding PHP modules, so
my
> Roundcube installation was broken for a few weeks.
To be fair it was only broken because you kept it broken; you could have
backed out the CR updates and waited for the point release to go GA and
be on ABI parity with EPEL.
> One of the things I like about Oracle Linux is that they maintain their own
> EPEL repo, most probably to prevent these things from happening.
I would be careful of expectations around that partial EPEL rebuild;
it's not complete and some of the builds are quite dated.







							John
-- 
Politicians are like a Slinky.
They're really not good for anything,
but they still bring a smile to your face
when you push them down a flight of stairs.

-- attribution unknown other except as a signature from shrdlu at deaddrop.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20210106/0ea970cc/attachment-0005.sig>

Le 06/01/2021 ? 08:48, John R. Dennison a ?crit?:
> To be fair it was only broken because you kept it broken; you could have
> backed out the CR updates and waited for the point release to go GA and
> be on ABI parity with EPEL.
I used the CR updates because back then the official repositories were lagging
far behind with security updates. But that's a different story.

Trying to roll back from this update resulted in a complete disaster.

-- 
Microlinux - Solutions informatiques durables
7, place de l'?glise - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : info at microlinux.fr
T?l. : 04 66 63 10 32
Mob. : 06 51 80 12 12

On 1/5/21 11:31 PM, Nicolas Kovacs wrote:
> No, this was an actual problem I had back in April 2020. Upgrading from CR
> broke imagemagick

At the time, you described that problem as:
> I got an alert from Yum-Cron this morning:
> Failed to check for updates with the following error message:
> Failed to build transaction: sclo-php72-php-pecl-imagick-3.4.4-1.el7.x86_64
> requires libMagickCore.so.5()(64bit)

I don't have enough information to say why imagemagick or php would be 
broken, as you said it was.

What I do see is that the sclo-php72-php-pecl-imagick has a dependency 
on libMagickCore.so.5()(64bit), which is recorded in the rpm package.? 
If you have a package from a third party repository (either EPEL or 
SCLO, or others), and it depends on one of the few packages in CentOS 
Stream (or CentOS, or RHEL) that aren't guaranteed to be stable, and 
which Red Hat changes, then yum will warn you that the update would 
result in unresolvable dependencies, and it won't upgrade the package.? 
Your system will keep the old imagemagick package and the old 
php-imagick package until the dependencies are resolved in the two 
repositories, and it'll update them after that.

Stream doesn't change that.