В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее:
verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3

Предлагаю долинковать плагины, после чего включить
%set_verify_elf_method strict

По-идее, postgis надо просто пересобрать под PG-11, поправив в спеке

%define pg_ver 10

на

%define pg_ver 11

По крайней мере у меня получилось собрать, поставить и запустить расширение postgresql11-postgis 2.5.1.

(В ответ на комментарий №2)
> По-идее, postgis надо просто пересобрать под PG-11, поправив в спеке
> 
> %define pg_ver 10
> 
> на
> 
> %define pg_ver 11
> 
> По крайней мере у меня получилось собрать, поставить и запустить расширение
> postgresql11-postgis 2.5.1.

Тогда каким образом переехать с postgresql10 у которого текущее расширение сломано, на postgresql11? Бакап сделать невозможно, базы бинарно не совместимы.

Откатить из архива последний рабочий postgis и далее по инструкции.

(В ответ на комментарий №4)
> Откатить из архива последний рабочий postgis и далее по инструкции.

Может все таки более корректным будет:
Собирать для postgres{X} devel пакеты которые провайдят только {names}{X}-devel
Для основной версии провайдить еще имя {names}-devel
Собрать postgis{X} расширение под текущие актуальные версии (9.4-11) опираясь на их {names}{X}-devel пакеты.
У утилит postgis вообще отпилить зависимость на postgres{X}-postgis так как это чисто клиентская часть, которая может быть установлена не там где установлена серверная.

Этап с несколькими -devel уже был. Не прижился по причине сразу же полезших конфликтов с линковкой, потому что помимо вручную прописанных provides rpmbuild генерит массу автоматических. В результате можно вообще не получить сборочную среду из-за конфликтов, либо приложение будет получать не ту версию, какая ей нужна.

(В ответ на комментарий №6)
> Этап с несколькими -devel уже был. Не прижился по причине сразу же полезших
> конфликтов с линковкой, потому что помимо вручную прописанных provides rpmbuild
> генерит массу автоматических. В результате можно вообще не получить сборочную
> среду из-за конфликтов, либо приложение будет получать не ту версию, какая ей
> нужна.

А можно детальней кого мое предложение потенциально разломает?

Удаление всех libpq кроме самой последней было следствием невозможности собрать части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек, подтягиваемых по автоматически созданным зависимостям set-version. Когда во время прохождения тестов сборка обламывалась на установке debug-пакетов - тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только вернуть, но еще и расширить за счет -devel.

Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть возможность сборки в опцией --with devel. В случае с postgis надо дождаться когда выкатят сборку под PG11. А до этого момента вернуться на последнюю работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По появлению пересобранного postgis провести обновление Hard Upgrade в документации postgis.

(In reply to comment #1)
> В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее:
> verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> SearchSysCache3
> 
> Предлагаю долинковать плагины, после чего включить
> %set_verify_elf_method strict

В качестве приятного побочного эффекта это изменение заблокирует возможность установить модуль postgis вместе с несовместимой версией libpq.

(В ответ на комментарий №9)
> (In reply to comment #1)
> > В логе сборки пакета postgis-2.5.1-alt2 написано буквально следующее:
> > verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > SearchSysCache3
> > 
> > Предлагаю долинковать плагины, после чего включить
> > %set_verify_elf_method strict
> 
> В качестве приятного побочного эффекта это изменение заблокирует возможность
> установить модуль postgis вместе с несовместимой версией libpq.

Именно расширение, насколько я понимаю, не линкуется на libpq, только клиентские утилиты, которые не сильно важны и могут быть собраны отдельно с любой угодной версией клиентской либы. 

Схожая ругань
"verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
Пример из сборки postgresql9.6
verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol: UtfToLocal
verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol: error_context_stack

(In reply to comment #10)
> Схожая ругань
> "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> Пример из сборки postgresql9.6
> verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> UtfToLocal
> verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> error_context_stack

А в каком файле определены эти символы и почему модули самого postgresql не линкуются с этим файлом?

(В ответ на комментарий №11)
> (In reply to comment #10)
> > Схожая ругань
> > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > Пример из сборки postgresql9.6
> > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > UtfToLocal
> > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > error_context_stack
> 
> А в каком файле определены эти символы и почему модули самого postgresql не
> линкуются с этим файлом?

Ну чисто предположение (пока нет возможности копнуть): динамическая загрузка расширений а символы внутри того кто грузит?

(В ответ на комментарий №11)
> (In reply to comment #10)
> > Схожая ругань
> > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > Пример из сборки postgresql9.6
> > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > UtfToLocal
> > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > error_context_stack
> 
> А в каком файле определены эти символы и почему модули самого postgresql не
> линкуются с этим файлом?

В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как  undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих объектов занимается сам процесс postgresql

(В ответ на комментарий №8)
> Удаление всех libpq кроме самой последней было следствием невозможности собрать
> части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек,
> подтягиваемых по автоматически созданным зависимостям set-version. Когда во
> время прохождения тестов сборка обламывалась на установке debug-пакетов -
> тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только
> вернуть, но еще и расширить за счет -devel.
> 
> Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть
> возможность сборки в опцией --with devel. В случае с postgis надо дождаться
> когда выкатят сборку под PG11. А до этого момента вернуться на последнюю
> работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По
> появлению пересобранного postgis провести обновление Hard Upgrade в
> документации postgis.

Собрал в хашере по приведенной мной выше идее (собрал 9.3 и 9.6 devel пакеты которые провайдят только версионированные devel), собрал postgis9.3 и postgis9.6 с указанием жестких зависимостей и отпиленными пакетами с клиентской частью, собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь что из-за postgres). Что вижу - собиралось с postgresql11-devel, так как только он провайдит postgresql-devel, в одном из пакетов bacula9 есть зачем-то жестко прописанная зависимость на postgresql10.

(In reply to comment #13)
> (В ответ на комментарий №11)
> > (In reply to comment #10)
> > > Схожая ругань
> > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > > Пример из сборки postgresql9.6
> > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > > UtfToLocal
> > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > > error_context_stack
> > 
> > А в каком файле определены эти символы и почему модули самого postgresql не
> > линкуются с этим файлом?
> 
> В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как 
> undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих
> объектов занимается сам процесс postgresql

А кто следит за правильным порядком загрузки плагинов, тоже posgresql?
Зачем такой закат солнца вручную?

Похожая схема используется в /usr/lib64/lftp/, но там в конеченом итоге справились с этой задачей нормально, в отличие от postgresql.

(В ответ на комментарий №14)
> (В ответ на комментарий №8)
> > Удаление всех libpq кроме самой последней было следствием невозможности собрать
> > части пакетов (конкретно это вылезло на bacula) ввиду конфликта библиотек,
> > подтягиваемых по автоматически созданным зависимостям set-version. Когда во
> > время прохождения тестов сборка обламывалась на установке debug-пакетов -
> > тянулись lib от совершенно другой ветки. Вы предлагаете кавардак не только
> > вернуть, но еще и расширить за счет -devel.
> > 
> > Это никому не нужно. Для совсем безвыходных ситуаций у пакетов postgresql есть
> > возможность сборки в опцией --with devel. В случае с postgis надо дождаться
> > когда выкатят сборку под PG11. А до этого момента вернуться на последнюю
> > работавшую комбинацию версий PG10 и postgis и поставить пакеты на холд. По
> > появлению пересобранного postgis провести обновление Hard Upgrade в
> > документации postgis.
> 
> Собрал в хашере по приведенной мной выше идее (собрал 9.3 и 9.6 devel пакеты
> которые провайдят только версионированные devel), собрал postgis9.3 и
> postgis9.6 с указанием жестких зависимостей и отпиленными пакетами с клиентской
> частью, собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь
> что из-за postgres). Что вижу - собиралось с postgresql11-devel, так как только
> он провайдит postgresql-devel, в одном из пакетов bacula9 есть зачем-то жестко
> прописанная зависимость на postgresql10.

Ошибся при наборе - не 9.3 а 9.4

(В ответ на комментарий №14)
> собрал bacula9 (отломав mysql часть ибо она не собиралась, сомневаюсь
> что из-за postgres)

начиная с 9.0.6-alt4 должна собираться

(In reply to comment #15)
> (In reply to comment #13)
> > (В ответ на комментарий №11)
> > > (In reply to comment #10)
> > > > Схожая ругань
> > > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > > > Пример из сборки postgresql9.6
> > > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > > > UtfToLocal
> > > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > > > error_context_stack
> > > 
> > > А в каком файле определены эти символы и почему модули самого postgresql не
> > > линкуются с этим файлом?
> > 
> > В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как 
> > undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих
> > объектов занимается сам процесс postgresql
> 
> А кто следит за правильным порядком загрузки плагинов, тоже posgresql?

Да.

> Зачем такой закат солнца вручную?

Возможно, разработчики посчитали это удобным.

> Похожая схема используется в /usr/lib64/lftp/, но там в конеченом итоге
> справились с этой задачей нормально, в отличие от postgresql.

Вообще-то postgres и так с этим справляется успешно. С идущими в комплекте расширениями проблем нет.

(В ответ на комментарий №13)
> (В ответ на комментарий №11)
> > (In reply to comment #10)
> > > Схожая ругань
> > > "verify-elf: WARNING: ./usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> > > SearchSysCache3" идет и в самом postgresql{x} на стандартные расширения
> > > Пример из сборки postgresql9.6
> > > verify-elf: WARNING: ./usr/lib64/pgsql/utf8_and_uhc.so: undefined symbol:
> > > UtfToLocal
> > > verify-elf: WARNING: ./usr/lib64/pgsql/plpython2.so: undefined symbol:
> > > error_context_stack
> > 
> > А в каком файле определены эти символы и почему модули самого postgresql не
> > линкуются с этим файлом?
> 
> В /usr/lib64/pgsql размещены расширения, фактически плагины. Помеченные как 
> undefined symbol предоставляются в соседних .so Загрузкой-выгрузкой этих
> объектов занимается сам процесс postgresql

Все таки настою на своем варианте ответа на вопрос Дмитрия.
Процесс postgresql динамически грузит нужные расширения.
Большая часть символов помеченных как undefined находятся в самом postgres (я думаю что вообще все, однако я это не проверял и утверждать не буду).
Насколько я вижу расширения не имеют связей между собой поэтому тут нет значения в каком порядке они грузятся (да и грузится будут только те которые подключены в базе).

Все стандартные расширения билдятся вместе с postgres, и с ними проблем нет.
Postgis же - отдельное расширение, для сборки которого нужна серверная часть devel.

Исходя из этого и понимая что вероятность появления devel пакетов крайне низка, есть еще вариант как сделать все таки по человечески, а не в варианте я вам тут поломал, а вы теперь сами разбирайтесь: 
Собирать postgis вместе с postgres, как будто он часть стандартных расширений.

postgis-2.5.2-alt1 -> sisyphus:

Tue Mar 19 2019 Andrey Cherepanov <cas@altlinux> 2.5.2-alt1
- New version.
- Require postgresql11 (ALT #36240).