Re: [devel] Сборка расширений PostgreSQL

[alexei@taf.ru]

----- Исходное сообщение -----
> От: "alexei" <alexei@taf.ru>
> Кому: "ALT Linux Team development discussions" <devel@lists.altlinux.org>
> Отправленные: Среда, 9 Февраль 2022 г 21:25:43
> Тема: Re: [devel] Сборка расширений   PostgreSQL

> ----- Исходное сообщение -----
>> От: "ldv" <ldv@altlinux.org>
>> Кому: "alexei" <alexei@taf.ru>
>> Копия: "ALT Linux Team development discussions" <devel@lists.altlinux.org>
>> Отправленные: Среда, 9 Февраль 2022 г 21:14:54
>> Тема: Re: [devel] Сборка расширений   PostgreSQL
> 
>> On Wed, Feb 09, 2022 at 08:51:08PM +0800, alexei@taf.ru wrote:
>> [...]
>>> Поправил
>>> 
>>> https://git.altlinux.org/tasks/294683/logs/events.4.1.log
>>> 
>>> girar-check-perms: access to kde5-kdb DENIED for taf: does not belong to
>>> approved builders list: zerg
>> 
>> Я посмотрел, какие изменения понадобилось сделать в этом пакете:
>> https://git.altlinux.org/tasks/294683/gears/1100/git?p=git;a=commitdiff;h=master
>> 
>> На мой взгляд, следующая часть изменения концепутально неправильная:
>> 
>> diff --git a/.gear/kdb.spec b/.gear/kdb.spec
>> index 7b37cc91..c68e9055 100644
>> --- a/.gear/kdb.spec
>> +++ b/.gear/kdb.spec
>> @@ -2,6 +2,7 @@
>> 
>> %define sover 4
>> %define libkdb3 libkdb3%sover
>> +%define pg_ver 14
>> 
>> Name: kde5-%rname
>> Version: 3.2.0
>> @@ -21,7 +22,7 @@ Source: %rname-%version.tar
>> BuildRequires(pre): rpm-build-kf5
>> BuildRequires: extra-cmake-modules qt5-base-devel qt5-wayland-devel
>> BuildRequires: libicu-devel
>> -BuildRequires: libmysqlclient-devel postgresql-devel sqlite3 libsqlite3-devel
>> +BuildRequires: libmysqlclient-devel postgresql%pg_ver-server-devel sqlite3
>> libsqlite3-devel
>> BuildRequires: kf5-kcoreaddons-devel
>> BuildRequires: rpm-build-python3 python3(shlex)
>> 
>> Пакет kdb не должен зашивать версию postgresql-server-devel в сборочные
>> зависимости.  Более того, никакой обычный пакет не должен этого делать,
>> вместо этого следует всегда использовать то, что является версией по
>> умолчанию в репозитории на момент сборки.
>> 
>> Например, одна из реализаций может содержать
>> "Provides: postgresql-server-devel".
> 
> Идея как раз в том, что если кому-то надо именно серверный API, то он должен
> четко понимать под какую ветку он собирает приложение, так как это API,
> в отличии от libpq обратно не совместимо.
> 
> Тут скорее надо смотреть внутрь самого приложения, реально ли ему надо
> лезть в серверный API, или может это какой-то атавизм, и вполне достаточно
> интерфейса libpq.

И еще, при сборке серверного расширения выбор к какой ветке линковаться происходит
на этапе написания спека. Потому что ситуация, когда расширение работает на старой
версии но ломается на новой и чинится апстримом где-то через полгода-год, это проза
жизни, пример - timescaledb.