Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s25yw-00HPEW-WC for pgsql-pkg-yum@arkaria.postgresql.org; Wed, 01 May 2024 09:10:30 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s25yu-00BylT-Im for pgsql-pkg-yum@arkaria.postgresql.org; Wed, 01 May 2024 09:10:29 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s25yu-00BylL-AK for pgsql-pkg-yum@lists.postgresql.org; Wed, 01 May 2024 09:10:29 +0000 Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s25yr-000uFm-V0 for pgsql-pkg-yum@postgresql.org; Wed, 01 May 2024 09:10:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-ID:Content-Description; bh=1fQC2AT4AvQwTOQU81eEg4W99x9Mx5w76ngZJdQeLeU=; b=h56qFxupsgC4p/6kojXEe5mIsZ t9mQbwsZenn5o0tSy0wbcWFEw0MppZ5GjAg2u/4NpzF/1b34OSffxlM2akf5Jnky5rq4NYwmYo9Ls RyGjQBEVPuUuFRItpk8AZ8qBX5kxwhki/6Vr3FX+hlNN2HoD7aLRlBd6BWKihonZLm+dx0FvzPtmq Wbd1/IqT6KIybqmlhFUtNdB4t6bwLCkdnZLeFIKaLJpZwPOGX/B6hwU/KQkaBhP1UrM/Y56JfXCJM /jysww2mcD1POfRD9FbTn4fQymwRLFNEdpY3ChqC4pMv4cAPW7y8hQLBgJOGDUi/jl9SrLtCbliCU oVIYgtCg==; Received: from authenticated user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.94.2) (envelope-from ) id 1s25yo-006gT3-8W; Wed, 01 May 2024 09:10:21 +0000 Date: Wed, 1 May 2024 11:10:20 +0200 From: Christoph Berg To: Devrim =?iso-8859-1?B?R/xuZPx6?= Cc: "Lorenz, Christopher" , "pgsql-pkg-yum@postgresql.org" Subject: Re: AW: postgis/gdal - undefined symbol: proj_crs_has_point_motion_operation Message-ID: Mail-Followup-To: Christoph Berg , Devrim =?iso-8859-1?B?R/xuZPx6?= , "Lorenz, Christopher" , "pgsql-pkg-yum@postgresql.org" References: <102a9afd1469446380ca72ded8de4df9@ZIT-BB.Brandenburg.de> <7a701d8cf9124ea5b2f1968f734b56e9@ZIT-BB.Brandenburg.de> <78fd412966536e4441e9bb3730d6441486d06c2e.camel@gunduz.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <78fd412966536e4441e9bb3730d6441486d06c2e.camel@gunduz.org> X-Debian-User: myon List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Re: Devrim Gündüz > > proj94-9.4.0-1PGDG.rhel8.x86_64 > > proj82-8.2.1-3.rhel8.x86_64 > > proj92-9.2.1-1PGDG.rhel8.x86_64 > > > The automatic update on my server doesn't removes the old proj92 > > package. Is it possible and practical to define conflicts with > > different proj versions in specs to avoid problems like these? > > I am not sure this is 100% safe. What happens when there is a PostGIS > version that cannot be compiled against newer Proj and someone wants to > install multiple PostGIS versions? The packages are renamed for the new SONAMEs exactly for being able to keep them around (there might be other software still using the older versions, perhaps locally compiled things). Forcing them to be removed would defeat that purpose. Christoph