Message-ID: <5e65c86d-f060-455c-8ffe-759164782f54@codematix.de>
Date: Wed, 24 Jan 2024 12:22:00 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: armadillo major update 10 to 12 in epel
To: =?UTF-8?B?RGV2cmltIEfDvG5kw7x6?= <devrim@gunduz.org>,
 pgsql-pkg-yum@postgresql.org
References: <6bf9ebfb-1ce4-4983-84eb-ae7765d3923f@codematix.de>
 <9a65b49c51a061fdea7768ed991923626606f21e.camel@gunduz.org>
From: Holger Schiebold <hschiebold@codematix.de>
In-Reply-To: <9a65b49c51a061fdea7768ed991923626606f21e.camel@gunduz.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/5e65c86d-f060-455c-8ffe-759164782f54%40codematix.de>
Precedence: bulk

Hi Devrim and thanks for the info,

the problem for us is i.e. on RHEL8 machines in the data center where 
some times ago a former Version of postgis31_12 
(postgis31_12-0:3.1.9-1.rhel8.x86_64) with dependency gdal34-libs was 
installed - now the "yum update" in an automatic patchcycle fails 
because gdal36-libs is not an update of gdal34-libs.
So we have to manually remove an all machines the gdal34-libs and 
reinstall the postgis package with the alternativ dependency gdal36-libs 
- right?

On RHEL9 same problem with i.e. older installs of  
postgis31_12-0:3.1.7-1.rhel9.x86_64 - (yum deplist 
postgis31_12-0:3.1.7-1.rhel9.x86_64 | grep gdal) - where gdal33-libs as 
dependency came with it.
On RHEL9 i.e. we have machines with installed postgis30 too with only 
dependency to gdal33-libs. There we cannot use postgis30 anymore - only 
higher Versions as fresh installs. (this is normally not possible in a 
specified production environment)

All manually tasks has to be done by a lot of different admins at each 
stage in the data center (dev, test, int, prod)

So would it be possible to build alle the gdal3* alternatives (gdal33, 
34, 35 ) too against the armadillo 12? Only in that case the next "yum 
update" is not broken - we think. Otherwise these Versions and postgis30 
in RHEL9 i.e. in the postgres yum repo must be considered as broken - 
right?


best regards

Holger


Am 23.01.2024 um 20:22 schrieb Devrim Gündüz:
> Hi,
>
> On Tue, 2024-01-23 at 14:54 +0100, Holger Schiebold wrote:
>> it seems that again armadillo major update in epel (this time from 10
>> to  12) breaks the gdal3* packages in postgres yum repos (RHEL 8 and
>> 9), so  we cannot use  certain packages from postgres el repositories
>> and yum  update on machines with both repositories is broken.
>>
>> Will there be builds of the gdal3*  packages against the new armadillo
>> 12 package from epel to solve that or do we have to do other things
>> while we use postgres and epel repositories?
> This has been fixed already in GDAL 3.6.4-6 RPMs.
>
>> Btw. - why the epel guys do major upgrades of this library - isn't it
>> completely against the el way of things? Was this ever discussed with
>> the epel guys?
> RHEL also do such updates with LLVM and CLANG, already broke poppler and
> armadillo in the past, so my job is to rebuild the packages on our side
> when such updates are released.
>
> Regards,


mit freundlichen Grüßen

-- 
Holger Schiebold


____________________
codematix GmbH
Felsbachstrasse 5/7
D-07745 Jena
Tel. +49 (3641) 3038-18
www.codematix.de