Re: [sisyphus] PostGIS и Postgres-ы

Re: [sisyphus] PostGIS и Postgres-ы

[Igor Zubkov]

On Wed, Mar 6, 2019 at 2:11 PM Игорь Андросов wrote:
> Вообще очень спорное решение билдить расширение, жестко завязанное на версию сервера, только для одной (последней мажорной) версии postgresql. При появлении новой мажорной версии postgresql происходит сборка с devel пакетом новой (так как для старых devel теперь нет), однако само расширение не переключается на новую, что ломает функционирование. Когда же происходит переключение, для старых версий postgresql расширения в репозитарии более не существует, хотя оно установлено и возможно используется.

Передавайте привет тому кто решил что старые версии -devel пакетов не
нужны для postgresql. Хотя это не так. Я сталкивался регулярно с тем
что мне нужен -devel пакет от старого postgresql что бы собрать новую
версию ruby gem pg при деплое. Прошло наверно уже пять лет, а воз и
ныне там.

Re: [sisyphus] PostGIS и Postgres-ы

[Igor Zubkov]

Может и будет. Но вот в таком случае не будет работать:
1. Делаем disc-upgrade
2. Получаем более новый postgresql уже без -devel части
3. Обновляем версию ruby через rbenv/rvm. В этот момент, pg джем уже
не соберётся из-за того что нужного -devel пакета уже нет.

Ну и привет, идём чинить. Сколько раз так уже было с packages.altlinux.org.

On Wed, Mar 6, 2019 at 2:33 PM Игорь Андросов <blacester@gmail.com> wrote:
>
> Разве gem pg это не клиентская часть, которая, могу ошибаться, будет работать на новой либе со старым сервером?
>
> ср, 6 мар. 2019 г. в 15:18, Igor Zubkov <igor.zubkov@gmail.com>:
>>
>> On Wed, Mar 6, 2019 at 2:11 PM Игорь Андросов wrote:
>> > Вообще очень спорное решение билдить расширение, жестко завязанное на версию сервера, только для одной (последней мажорной) версии postgresql. При появлении новой мажорной версии postgresql происходит сборка с devel пакетом новой (так как для старых devel теперь нет), однако само расширение не переключается на новую, что ломает функционирование. Когда же происходит переключение, для старых версий postgresql расширения в репозитарии более не существует, хотя оно установлено и возможно используется.
>>
>> Передавайте привет тому кто решил что старые версии -devel пакетов не
>> нужны для postgresql. Хотя это не так. Я сталкивался регулярно с тем
>> что мне нужен -devel пакет от старого postgresql что бы собрать новую
>> версию ruby gem pg при деплое. Прошло наверно уже пять лет, а воз и
>> ныне там.
>> _______________________________________________
>> Sisyphus mailing list
>> Sisyphus@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/sisyphus
>
>
>
> --
> С уважением Игорь.
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Igor Zubkov" <igor.zubkov@gmail.com>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправлено: Среда, 6 Март 2019 г 21:00:00
> Тема: Re: [sisyphus] PostGIS и Postgres-ы
> 
> Может и будет. Но вот в таком случае не будет работать:
> 1. Делаем disc-upgrade
> 2. Получаем более новый postgresql уже без -devel части
> 3. Обновляем версию ruby через rbenv/rvm. В этот момент, pg джем уже
> не соберётся из-за того что нужного -devel пакета уже нет.

Погодите. Тут свалили в кучу много странного. Сейчас специально собрал
PG10 c --with devel (опция специально сделана для сложных локальных случаев),
поставил в систему все пакеты:

$ sudo apt-get install libecpg6.10-10.7-alt1.x86_64.rpm libecpg6.10-devel-10.7-alt1.x86_64.rpm libecpg6.10-devel-static-10.7-alt1.x86_64.rpm libpq5.10-10.7-alt1.x86_64.rpm libpq5.10-devel-10.7-alt1.x86_64.rpm libpq5.10-devel-static-10.7-alt1.x86_64.rpm postgresql10-devel-10.7-alt1.x86_64.rpm postgresql10-10.7-alt1.x86_64.rpm postgresql10-contrib-10.7-alt1.x86_64.rpm postgresql10-devel-static-10.7-alt1.x86_64.rpm postgresql10-server-10.7-alt1.x86_64.rpm
[sudo] password for taf:
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Выбрано libecpg6.10 для 'libecpg6.10-10.7-alt1.x86_64.rpm'
Выбрано libecpg6.10-devel для 'libecpg6.10-devel-10.7-alt1.x86_64.rpm'
Выбрано libecpg6.10-devel-static для 'libecpg6.10-devel-static-10.7-alt1.x86_64.rpm'
Выбрано libpq5.10 для 'libpq5.10-10.7-alt1.x86_64.rpm'
Выбрано libpq5.10-devel для 'libpq5.10-devel-10.7-alt1.x86_64.rpm'
Выбрано libpq5.10-devel-static для 'libpq5.10-devel-static-10.7-alt1.x86_64.rpm'
Выбрано postgresql10-devel для 'postgresql10-devel-10.7-alt1.x86_64.rpm'
Выбрано postgresql10 для 'postgresql10-10.7-alt1.x86_64.rpm'
Выбрано postgresql10-contrib для 'postgresql10-contrib-10.7-alt1.x86_64.rpm'
Выбрано postgresql10-devel-static для 'postgresql10-devel-static-10.7-alt1.x86_64.rpm'
Выбрано postgresql10-server для 'postgresql10-server-10.7-alt1.x86_64.rpm'
Следующие пакеты будут УДАЛЕНЫ:
  libpq5.11
Следующие НОВЫЕ пакеты будут установлены:
  libecpg6.10 libecpg6.10-devel libecpg6.10-devel-static libpq5.10 libpq5.10-devel libpq5.10-devel-static postgresql10
  postgresql10-contrib postgresql10-devel postgresql10-devel-static postgresql10-server
0 будет обновлено, 11 новых установлено, 1 пакетов будет удалено и 0 не будет обновлено.
Необходимо получить 0B/9946kB архивов.
После распаковки потребуется дополнительно 38,7MB дискового пространства.
Продолжить? [Y/n] y
Совершаем изменения...  
Подготовка...                           ########################################################################## [100%]
Обновление / установка...
 1: libpq5.10-10.7-alt1                 ########################################################################## [  8%]
 2: libpq5.10-devel-10.7-alt1           ########################################################################## [ 17%]
 3: postgresql10-10.7-alt1              ########################################################################## [ 25%]
 4: libecpg6.10-10.7-alt1               ########################################################################## [ 33%]
 5: libecpg6.10-devel-10.7-alt1         ########################################################################## [ 42%]
 6: postgresql10-devel-10.7-alt1        ########################################################################## [ 50%]
 7: postgresql10-devel-static-10.7-alt1 ########################################################################## [ 58%]
 8: libecpg6.10-devel-static-10.7-alt1  ########################################################################## [ 67%]
 9: postgresql10-contrib-10.7-alt1      ########################################################################## [ 75%]
10: postgresql10-server-10.7-alt1       ########################################################################## [ 83%]
11: libpq5.10-devel-static-10.7-alt1    ########################################################################## [ 92%]
Очистка / удаление... 
12: libpq5.11-11.2-alt1                 ########################################################################## [100%]
Завершено.

Как видим, все поставилось, и по пути была вынесена клиентская библиотека от PG11
После чего делаем:

$ sudo apt-get dist-upgrade
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Подсчет обновлений... Завершено
0 будет обновлено, 0 новых установлено, 0 пакетов будет удалено и 0 не будет обновлено.

...и ничего. apt даже не пытается ни заменить пакеты от PG10 на пакеты от PG11. И сделано это специально. И любой переход
с с одной мажорной версии на другую это всегда вручную выполняемая операция.

А теперь говорим:

$ sudo apt-get install libpq5.11
[sudo] password for taf:
Чтение списков пакетов... Завершено
Построение дерева зависимостей... Завершено
Следующие пакеты будут УДАЛЕНЫ:
  libecpg6.10 libecpg6.10-devel libecpg6.10-devel-static libpq5.10 libpq5.10-devel libpq5.10-devel-static postgresql10
  postgresql10-contrib postgresql10-devel postgresql10-devel-static postgresql10-server
Следующие НОВЫЕ пакеты будут установлены:
  libpq5.11
0 будет обновлено, 1 новых установлено, 11 пакетов будет удалено и 0 не будет обновлено.
Необходимо получить 0B/169kB архивов.
После распаковки будет освобождено 38,7MB дискового пространства.
Продолжить? [Y/n] y
Совершаем изменения...  
Подготовка...                           ########################################################################## [100%]
Обновление / установка...
 1: libpq5.11-11.2-alt1                 ########################################################################## [  8%]
Очистка / удаление... 
 2: libpq5.10-devel-static-10.7-alt1    ########################################################################## [ 17%]
 3: postgresql10-server-10.7-alt1       ########################################################################## [ 25%]
Failed to preset unit: Unit file postgresql.service does not exist.
 4: postgresql10-contrib-10.7-alt1      ########################################################################## [ 33%]
 5: postgresql10-10.7-alt1              ########################################################################## [ 42%]
 6: libecpg6.10-devel-static-10.7-alt1  ########################################################################## [ 50%]
 7: postgresql10-devel-static-10.7-alt1 ########################################################################## [ 58%]
 8: postgresql10-devel-10.7-alt1        ########################################################################## [ 67%]
 9: libpq5.10-devel-10.7-alt1           ########################################################################## [ 75%]
10: libecpg6.10-devel-10.7-alt1         ########################################################################## [ 83%]
11: libecpg6.10-10.7-alt1               ########################################################################## [ 92%]
12: libpq5.10-10.7-alt1                 ########################################################################## [100%]
Завершено.


Хоба! Вынесло не только клиентскую либу и как бы ожидаемые -devel, а вылетел вообще весь PG10.

Re: [sisyphus] PostGIS и Postgres-ы

[Igor Zubkov]

On Thu, Mar 7, 2019 at 6:04 AM Alexei Takaseev wrote:
> > Может и будет. Но вот в таком случае не будет работать:
> > 1. Делаем disc-upgrade
> > 2. Получаем более новый postgresql уже без -devel части
> > 3. Обновляем версию ruby через rbenv/rvm. В этот момент, pg джем уже
> > не соберётся из-за того что нужного -devel пакета уже нет.
>
> Погодите. Тут свалили в кучу много странного. Сейчас специально собрал
> PG10 c --with devel (опция специально сделана для сложных локальных случаев),
> поставил в систему все пакеты:

Не надо ничего ни с чем собирать. Собрать то я могу на сервере, но хочу.

Давайте ещё раз. Если обновляется postgresql с одной большой версии на
другую, у старой поднимается версия (alt + 1) и удаляется -devel
пакеты. Ну и при dist-upgrade пакеты с postgresql обновляется до
нового билда (который alt + 1) и сносятся -devel.

Сделайте уже пожалуйста простую вещь, при сборке нового postgresql не
удаляйте старые -devel пакеты. И если уж так охота феншуя, запретите
через sisyphus_check сборочные зависимости на старые -devel пакеты.

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

----- 7 Мар 2019 г. в 20:01 Igor Zubkov igor.zubkov@gmail.com написал(а):

> On Thu, Mar 7, 2019 at 6:04 AM Alexei Takaseev wrote:
>> > Может и будет. Но вот в таком случае не будет работать:
>> > 1. Делаем disc-upgrade
>> > 2. Получаем более новый postgresql уже без -devel части
>> > 3. Обновляем версию ruby через rbenv/rvm. В этот момент, pg джем уже
>> > не соберётся из-за того что нужного -devel пакета уже нет.
>>
>> Погодите. Тут свалили в кучу много странного. Сейчас специально собрал
>> PG10 c --with devel (опция специально сделана для сложных локальных случаев),
>> поставил в систему все пакеты:
> 
> Не надо ничего ни с чем собирать. Собрать то я могу на сервере, но хочу.
> 
> Давайте ещё раз. Если обновляется postgresql с одной большой версии на
> другую, у старой поднимается версия (alt + 1) и удаляется -devel
> пакеты. Ну и при dist-upgrade пакеты с postgresql обновляется до
> нового билда (который alt + 1) и сносятся -devel.

Нет, не так, уже установленный в системе -devel не удаляется, я специально проверил
этот момент - обновляется только клиенты библиотеки, но не сама библиотека и -devel
обвязка. Просто при apt-cache list-extras они будут отображаться как не входящие в
репозиторий.

> Сделайте уже пожалуйста простую вещь, при сборке нового postgresql не
> удаляйте старые -devel пакеты. И если уж так охота феншуя, запретите
> через sisyphus_check сборочные зависимости на старые -devel пакеты.

Мне любопытно что же такое себе требует pg гем, что его плющит от годами
не менявшегося API и совершенно прозрачного для клиентов ABI?

Re: [sisyphus] PostGIS и Postgres-ы

[Igor Zubkov]

On Thu, Mar 7, 2019 at 2:49 PM Alexei Takaseev <alexei@taf.ru> wrote:
>
>
>
> ----- 7 Мар 2019 г. в 20:01 Igor Zubkov igor.zubkov@gmail.com написал(а):
>
> > On Thu, Mar 7, 2019 at 6:04 AM Alexei Takaseev wrote:
> >> > Может и будет. Но вот в таком случае не будет работать:
> >> > 1. Делаем disc-upgrade
> >> > 2. Получаем более новый postgresql уже без -devel части
> >> > 3. Обновляем версию ruby через rbenv/rvm. В этот момент, pg джем уже
> >> > не соберётся из-за того что нужного -devel пакета уже нет.
> >>
> >> Погодите. Тут свалили в кучу много странного. Сейчас специально собрал
> >> PG10 c --with devel (опция специально сделана для сложных локальных случаев),
> >> поставил в систему все пакеты:
> >
> > Не надо ничего ни с чем собирать. Собрать то я могу на сервере, но хочу.
> >
> > Давайте ещё раз. Если обновляется postgresql с одной большой версии на
> > другую, у старой поднимается версия (alt + 1) и удаляется -devel
> > пакеты. Ну и при dist-upgrade пакеты с postgresql обновляется до
> > нового билда (который alt + 1) и сносятся -devel.
>
> Нет, не так, уже установленный в системе -devel не удаляется, я специально проверил
> этот момент - обновляется только клиенты библиотеки, но не сама библиотека и -devel
> обвязка. Просто при apt-cache list-extras они будут отображаться как не входящие в
> репозиторий.

Тот который из репозитория
https://packages.altlinux.org/en/sisyphus/specfiles/postgresql10

%package -n %libpq_name-devel
Summary: Development shared library for %libpq_name
Group: Development/Databases
Requires: %libpq_name = %version-%release
Provides: libpq-devel = %version-%release
Conflicts: libpq-devel < %version-%release
Conflicts: libpq-devel > %version-%release
Provides: libpq%libpq_major-devel = %version-%release
Conflicts: libpq%libpq_major-devel < %version-%release
Conflicts: libpq%libpq_major-devel > %version-%release

Этот -devel пакет удалится при dist-upgrade.

> > Сделайте уже пожалуйста простую вещь, при сборке нового postgresql не
> > удаляйте старые -devel пакеты. И если уж так охота феншуя, запретите
> > через sisyphus_check сборочные зависимости на старые -devel пакеты.
>
> Мне любопытно что же такое себе требует pg гем, что его плющит от годами
> не менявшегося API и совершенно прозрачного для клиентов ABI?

Ничего. Просто наличие -devel пакетов от текущего postgresql.

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Igor Zubkov" <igor.zubkov@gmail.com>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправлено: Четверг, 7 Март 2019 г 21:28:55
> Тема: Re: [sisyphus] PostGIS и Postgres-ы
> 
> On Thu, Mar 7, 2019 at 2:49 PM Alexei Takaseev <alexei@taf.ru> wrote:
> >
> >
> >
> > ----- 7 Мар 2019 г. в 20:01 Igor Zubkov igor.zubkov@gmail.com
> > написал(а):
> >
> > > On Thu, Mar 7, 2019 at 6:04 AM Alexei Takaseev wrote:
> > >> > Может и будет. Но вот в таком случае не будет работать:
> > >> > 1. Делаем disc-upgrade
> > >> > 2. Получаем более новый postgresql уже без -devel части
> > >> > 3. Обновляем версию ruby через rbenv/rvm. В этот момент, pg
> > >> > джем уже
> > >> > не соберётся из-за того что нужного -devel пакета уже нет.
> > >>
> > >> Погодите. Тут свалили в кучу много странного. Сейчас специально
> > >> собрал
> > >> PG10 c --with devel (опция специально сделана для сложных
> > >> локальных случаев),
> > >> поставил в систему все пакеты:
> > >
> > > Не надо ничего ни с чем собирать. Собрать то я могу на сервере,
> > > но хочу.
> > >
> > > Давайте ещё раз. Если обновляется postgresql с одной большой
> > > версии на
> > > другую, у старой поднимается версия (alt + 1) и удаляется -devel
> > > пакеты. Ну и при dist-upgrade пакеты с postgresql обновляется до
> > > нового билда (который alt + 1) и сносятся -devel.
> >
> > Нет, не так, уже установленный в системе -devel не удаляется, я
> > специально проверил
> > этот момент - обновляется только клиенты библиотеки, но не сама
> > библиотека и -devel
> > обвязка. Просто при apt-cache list-extras они будут отображаться
> > как не входящие в
> > репозиторий.
> 
> Тот который из репозитория
> https://packages.altlinux.org/en/sisyphus/specfiles/postgresql10
> 
> %package -n %libpq_name-devel
> Summary: Development shared library for %libpq_name
> Group: Development/Databases
> Requires: %libpq_name = %version-%release
> Provides: libpq-devel = %version-%release
> Conflicts: libpq-devel < %version-%release
> Conflicts: libpq-devel > %version-%release
> Provides: libpq%libpq_major-devel = %version-%release
> Conflicts: libpq%libpq_major-devel < %version-%release
> Conflicts: libpq%libpq_major-devel > %version-%release
> 
> Этот -devel пакет удалится при dist-upgrade.

Уже установленные пакеты, удаленные из репо, не удаляются. Я специально проверил
этот сценарий. Вот если вы попытаетесь в системе с libpq10 доставить libpq11 то тогда да,
все следы десятки будут вынесены.

> > > Сделайте уже пожалуйста простую вещь, при сборке нового
> > > postgresql не
> > > удаляйте старые -devel пакеты. И если уж так охота феншуя,
> > > запретите
> > > через sisyphus_check сборочные зависимости на старые -devel
> > > пакеты.
> >
> > Мне любопытно что же такое себе требует pg гем, что его плющит от
> > годами
> > не менявшегося API и совершенно прозрачного для клиентов ABI?
> 
> Ничего. Просто наличие -devel пакетов от текущего postgresql.

Для таких сильных духом оставлен --with devel .

Re: [sisyphus] переименование библиотеки libpq

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

On Fri, Mar 08, 2019 at 10:22:10PM +0800, Alexei Takaseev wrote:
[...]
> Уже установленные пакеты, удаленные из репо, не удаляются. Я специально проверил
> этот сценарий. Вот если вы попытаетесь в системе с libpq10 доставить libpq11 то тогда да,
> все следы десятки будут вынесены.

Давно хотел спросить, зачем пакет с библиотекой libpq у каждой версии
postgresql переименовывается?  Там что, ABI всё время меняется?
Вроде бы нет, ведь soname там всё время один и тот же: libpq.so.5.

Я вижу, что ABI в libpq5.11 по сравнению с libpq5.10 не поменялся,
в libpq5.10 по сравнению с libpq5.9 была добавлена одна функция,
а в libpq5.9 по сравнению с libpq5.8 были добавлены ещё две
функции, но это же не повод для переименования пакета, правда?

Для сравнения, у нас в репозитории есть пакет libgcc1, который по мере
обновления кочует из одного gcc в другой, но мы не переименовываем пакет
libgcc1, потому что в нём реализована обратная совместимость по ABI.
Точнее говоря, мы отказались от переименовывания пакета с libgcc_s
7 лет назад.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [sisyphus] переименование библиотеки libpq

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Dmitry V. Levin" <ldv@altlinux.org>
> Кому: "ALT Sisyphus mailing list" <sisyphus@lists.altlinux.org>
> Отправлено: Пятница, 8 Март 2019 г 22:39:26
> Тема: Re: [sisyphus] переименование библиотеки libpq
> 
> On Fri, Mar 08, 2019 at 10:22:10PM +0800, Alexei Takaseev wrote:
> [...]
> > Уже установленные пакеты, удаленные из репо, не удаляются. Я
> > специально проверил
> > этот сценарий. Вот если вы попытаетесь в системе с libpq10
> > доставить libpq11 то тогда да,
> > все следы десятки будут вынесены.
> 
> Давно хотел спросить, зачем пакет с библиотекой libpq у каждой версии
> postgresql переименовывается?  Там что, ABI всё время меняется?
> Вроде бы нет, ведь soname там всё время один и тот же: libpq.so.5.
> 
> Я вижу, что ABI в libpq5.11 по сравнению с libpq5.10 не поменялся,
> в libpq5.10 по сравнению с libpq5.9 была добавлена одна функция,
> а в libpq5.9 по сравнению с libpq5.8 были добавлены ещё две
> функции, но это же не повод для переименования пакета, правда?

По каким-то причинам разработчики так поступают. Я не вижу смысла как-то
эту схему менять. Опять же, собранные даже 15 лет назад приложения вполне себе
работают и с современной библиотекой. Возможно этот как раз как-то связанно
со сборкой серверных расширений.

Re: [sisyphus] переименование библиотеки libpq

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

On Fri, Mar 08, 2019 at 10:45:44PM +0800, Alexei Takaseev wrote:
> > On Fri, Mar 08, 2019 at 10:22:10PM +0800, Alexei Takaseev wrote:
> > [...]
> > > Уже установленные пакеты, удаленные из репо, не удаляются. Я
> > > специально проверил
> > > этот сценарий. Вот если вы попытаетесь в системе с libpq10
> > > доставить libpq11 то тогда да,
> > > все следы десятки будут вынесены.
> > 
> > Давно хотел спросить, зачем пакет с библиотекой libpq у каждой версии
> > postgresql переименовывается?  Там что, ABI всё время меняется?
> > Вроде бы нет, ведь soname там всё время один и тот же: libpq.so.5.
> > 
> > Я вижу, что ABI в libpq5.11 по сравнению с libpq5.10 не поменялся,
> > в libpq5.10 по сравнению с libpq5.9 была добавлена одна функция,
> > а в libpq5.9 по сравнению с libpq5.8 были добавлены ещё две
> > функции, но это же не повод для переименования пакета, правда?
> 
> По каким-то причинам разработчики так поступают.

Так нет же, это не разработчики так поступают, это мы так поступаем.

> Я не вижу смысла как-то эту схему менять.

Вам бы понравилось, если бы пакет с библиотекой libgcc_s назывался бы не
libgcc1, как сейчас, а libgcc3.2, libgcc3.3, libgcc3.4, libgcc4.1,
libgcc4.3, libgcc4.4, libgcc4.5, и т.д., как на самом деле это было
у нас раньше?
Переименование пакета создаёт дополнительные сложности, зачем они нам?

> Опять же, собранные даже 15 лет назад приложения вполне себе
> работают и с современной библиотекой.

Тем более.
Тот факт, что при обновлении postgresql нам не приходится перелинковывать
все приложения с новой версий -lpq, дополнительно говорит в пользу того,
что переименование библиотеки libpq при обновлении postgresql
не является рациональным.

> Возможно этот как раз как-то связанно со сборкой серверных расширений.

Разве серверные расширения не находятся на стороне сервера?
Мы говорим про libpq, это же клиентская библиотека?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [sisyphus] переименование библиотеки libpq

[Alexei Takaseev]

----- Исходное сообщение -----
> От: "Dmitry V. Levin" <ldv@altlinux.org>
> Кому: "ALT Sisyphus mailing list" <sisyphus@lists.altlinux.org>
> Отправлено: Пятница, 8 Март 2019 г 22:56:59
> Тема: Re: [sisyphus] переименование библиотеки libpq
> 
> On Fri, Mar 08, 2019 at 10:45:44PM +0800, Alexei Takaseev wrote:
> > > On Fri, Mar 08, 2019 at 10:22:10PM +0800, Alexei Takaseev wrote:
> > > [...]
> > > > Уже установленные пакеты, удаленные из репо, не удаляются. Я
> > > > специально проверил
> > > > этот сценарий. Вот если вы попытаетесь в системе с libpq10
> > > > доставить libpq11 то тогда да,
> > > > все следы десятки будут вынесены.
> > > 
> > > Давно хотел спросить, зачем пакет с библиотекой libpq у каждой
> > > версии
> > > postgresql переименовывается?  Там что, ABI всё время меняется?
> > > Вроде бы нет, ведь soname там всё время один и тот же:
> > > libpq.so.5.
> > > 
> > > Я вижу, что ABI в libpq5.11 по сравнению с libpq5.10 не
> > > поменялся,
> > > в libpq5.10 по сравнению с libpq5.9 была добавлена одна функция,
> > > а в libpq5.9 по сравнению с libpq5.8 были добавлены ещё две
> > > функции, но это же не повод для переименования пакета, правда?
> > 
> > По каким-то причинам разработчики так поступают.
> 
> Так нет же, это не разработчики так поступают, это мы так поступаем.

so-name меняется разработчиками

> > Я не вижу смысла как-то эту схему менять.
> 
> Вам бы понравилось, если бы пакет с библиотекой libgcc_s назывался бы
> не
> libgcc1, как сейчас, а libgcc3.2, libgcc3.3, libgcc3.4, libgcc4.1,
> libgcc4.3, libgcc4.4, libgcc4.5, и т.д., как на самом деле это было
> у нас раньше?

Заглянул в содержимое libgcc1, там файл libgcc_s.so.1, в то время как
у libpq сонеймы меняются. И это не я их переименовываю.

> Переименование пакета создаёт дополнительные сложности, зачем они
> нам?

Каких-то сложностей не заметил, особенно когда осталась только одна версия
библиотеке в репо.

> > Опять же, собранные даже 15 лет назад приложения вполне себе
> > работают и с современной библиотекой.
> 
> Тем более.
> Тот факт, что при обновлении postgresql нам не приходится
> перелинковывать
> все приложения с новой версий -lpq, дополнительно говорит в пользу
> того,
> что переименование библиотеки libpq при обновлении postgresql
> не является рациональным.
> 
> > Возможно этот как раз как-то связанно со сборкой серверных
> > расширений.
> 
> Разве серверные расширения не находятся на стороне сервера?
> Мы говорим про libpq, это же клиентская библиотека?

Через память процесса postgres расширения тоже используют клиентские
библиотеки.

Re: [sisyphus] переименование библиотеки libpq

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

On Fri, Mar 08, 2019 at 11:11:39PM +0800, Alexei Takaseev wrote:
> > On Fri, Mar 08, 2019 at 10:45:44PM +0800, Alexei Takaseev wrote:
> > > > On Fri, Mar 08, 2019 at 10:22:10PM +0800, Alexei Takaseev wrote:
> > > > [...]
> > > > > Уже установленные пакеты, удаленные из репо, не удаляются. Я
> > > > > специально проверил
> > > > > этот сценарий. Вот если вы попытаетесь в системе с libpq10
> > > > > доставить libpq11 то тогда да,
> > > > > все следы десятки будут вынесены.
> > > > 
> > > > Давно хотел спросить, зачем пакет с библиотекой libpq у каждой
> > > > версии
> > > > postgresql переименовывается?  Там что, ABI всё время меняется?
> > > > Вроде бы нет, ведь soname там всё время один и тот же:
> > > > libpq.so.5.
> > > > 
> > > > Я вижу, что ABI в libpq5.11 по сравнению с libpq5.10 не
> > > > поменялся,
> > > > в libpq5.10 по сравнению с libpq5.9 была добавлена одна функция,
> > > > а в libpq5.9 по сравнению с libpq5.8 были добавлены ещё две
> > > > функции, но это же не повод для переименования пакета, правда?
> > > 
> > > По каким-то причинам разработчики так поступают.
> > 
> > Так нет же, это не разработчики так поступают, это мы так поступаем.
> 
> so-name меняется разработчиками

Подождите, у libpq5.* всегда один и тот же soname libpq.so.5, разве нет?

> > > Я не вижу смысла как-то эту схему менять.
> > 
> > Вам бы понравилось, если бы пакет с библиотекой libgcc_s назывался бы
> > не
> > libgcc1, как сейчас, а libgcc3.2, libgcc3.3, libgcc3.4, libgcc4.1,
> > libgcc4.3, libgcc4.4, libgcc4.5, и т.д., как на самом деле это было
> > у нас раньше?
> 
> Заглянул в содержимое libgcc1, там файл libgcc_s.so.1, в то время как
> у libpq сонеймы меняются. И это не я их переименовываю.

Но у libpq5 сонеймы НЕ меняются.

Вы не помните, как давно у libpq нынешний soname libpq.so.5?
Не с версии ли postgresql 8.2, вышедшей более 10 лет назад?

Я сейчас специально сравнил libpq5.0-8.2.11-alt0.M40.1.x86_64.rpm с
libpq5.11-11.2-alt1.x86_64.rpm, в новой версии по сравнению со старой
добавлено 36 символов и не удалено ни одного.

> > Переименование пакета создаёт дополнительные сложности, зачем они
> > нам?
> 
> Каких-то сложностей не заметил, особенно когда осталась только одна версия
> библиотеке в репо.

У вас никогда не было необходимости обновлять систему с одной libpq5.*
до другой?

Представьте себе, что, руководствуясь вашей логикой, все мантейнеры будут
переименовывать имя каждого пакета с библиотекой при каждом обновлении
пакета?  Просто представьте себе, что пакет libgcc1 будет называться
libgcc1.%version-%release просто потому, что это технически возможно.
В каждый момент времени в репозитории будет только один
libgcc1 по имени libgcc1.%version-%release, но это имя при каждом
обновлении будет другое.  Как вы думаете, от этого репозиторий станет
лучше или хуже нынешнего?

> > > Опять же, собранные даже 15 лет назад приложения вполне себе
> > > работают и с современной библиотекой.
> > 
> > Тем более.
> > Тот факт, что при обновлении postgresql нам не приходится
> > перелинковывать
> > все приложения с новой версий -lpq, дополнительно говорит в пользу
> > того,
> > что переименование библиотеки libpq при обновлении postgresql
> > не является рациональным.
> > 
> > > Возможно этот как раз как-то связанно со сборкой серверных
> > > расширений.
> > 
> > Разве серверные расширения не находятся на стороне сервера?
> > Мы говорим про libpq, это же клиентская библиотека?
> 
> Через память процесса postgres расширения тоже используют клиентские
> библиотеки.

Отлично, пусть расширения так и остаются в памяти процесса postgres
на серверной стороне.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

----- Исходное сообщение ----- 

> От: "Alexey Shabalin" <a.shabalin@gmail.com>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправлено: Пятница, 8 Март 2019 г 22:28:43
> Тема: Re: [sisyphus] PostGIS и Postgres-ы

> пт, 8 мар. 2019 г., 17:22 Alexei Takaseev < alexei@taf.ru >:

> > ----- Исходное сообщение -----
> 
> > > От: "Igor Zubkov" < igor.zubkov@gmail.com >
> 
> > > Кому: "ALT Linux Sisyphus discussions" <
> > > sisyphus@lists.altlinux.org >
> 
> > > Отправлено: Четверг, 7 Март 2019 г 21:28:55
> 
> > > Тема: Re: [sisyphus] PostGIS и Postgres-ы
> 
> > >
> 
> > > On Thu, Mar 7, 2019 at 2:49 PM Alexei Takaseev < alexei@taf.ru >
> > > wrote:
> 
> > > >
> 
> > > >
> 
> > > >
> 
> > > > ----- 7 Мар 2019 г. в 20:01 Igor Zubkov igor.zubkov@gmail.com
> 
> > > > написал(а):
> 
> > > >
> 
> > > > > On Thu, Mar 7, 2019 at 6:04 AM Alexei Takaseev wrote:
> 
> > > > >> > Может и будет. Но вот в таком случае не будет работать:
> 
> > > > >> > 1. Делаем disc-upgrade
> 
> > > > >> > 2. Получаем более новый postgresql уже без -devel части
> 
> > > > >> > 3. Обновляем версию ruby через rbenv/rvm. В этот момент,
> > > > >> > pg
> 
> > > > >> > джем уже
> 
> > > > >> > не соберётся из-за того что нужного -devel пакета уже нет.
> 
> > > > >>
> 
> > > > >> Погодите. Тут свалили в кучу много странного. Сейчас
> > > > >> специально
> 
> > > > >> собрал
> 
> > > > >> PG10 c --with devel (опция специально сделана для сложных
> 
> > > > >> локальных случаев),
> 
> > > > >> поставил в систему все пакеты:
> 
> > > > >
> 
> > > > > Не надо ничего ни с чем собирать. Собрать то я могу на
> > > > > сервере,
> 
> > > > > но хочу.
> 
> > > > >
> 
> > > > > Давайте ещё раз. Если обновляется postgresql с одной большой
> 
> > > > > версии на
> 
> > > > > другую, у старой поднимается версия (alt + 1) и удаляется
> > > > > -devel
> 
> > > > > пакеты. Ну и при dist-upgrade пакеты с postgresql обновляется
> > > > > до
> 
> > > > > нового билда (который alt + 1) и сносятся -devel.
> 
> > > >
> 
> > > > Нет, не так, уже установленный в системе -devel не удаляется, я
> 
> > > > специально проверил
> 
> > > > этот момент - обновляется только клиенты библиотеки, но не сама
> 
> > > > библиотека и -devel
> 
> > > > обвязка. Просто при apt-cache list-extras они будут
> > > > отображаться
> 
> > > > как не входящие в
> 
> > > > репозиторий.
> 
> > >
> 
> > > Тот который из репозитория
> 
> > > https://packages.altlinux.org/en/sisyphus/specfiles/postgresql10
> 
> > >
> 
> > > %package -n %libpq_name-devel
> 
> > > Summary: Development shared library for %libpq_name
> 
> > > Group: Development/Databases
> 
> > > Requires: %libpq_name = %version-%release
> 
> > > Provides: libpq-devel = %version-%release
> 
> > > Conflicts: libpq-devel < %version-%release
> 
> > > Conflicts: libpq-devel > %version-%release
> 
> > > Provides: libpq%libpq_major-devel = %version-%release
> 
> > > Conflicts: libpq%libpq_major-devel < %version-%release
> 
> > > Conflicts: libpq%libpq_major-devel > %version-%release
> 
> > >
> 
> > > Этот -devel пакет удалится при dist-upgrade.
> 

> > Уже установленные пакеты, удаленные из репо, не удаляются. Я
> > специально проверил
> 
> > этот сценарий. Вот если вы попытаетесь в системе с libpq10
> > доставить
> > libpq11 то тогда да,
> 
> > все следы десятки будут вынесены.
> 

> Ну это же полная лажа. Тогда нет никакого смысла добавлять 10 и 11 к
> libpq, если нельзя их одновременно установить.

Этого и не делается. Сейчас в репо есть только libpq11. Выйдет 12-я версия,
будет заменена на libpq12

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

----- Исходное сообщение ----- 

> От: "Alexey Shabalin" <a.shabalin@gmail.com>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправлено: Пятница, 8 Март 2019 г 22:28:43
> Тема: Re: [sisyphus] PostGIS и Postgres-ы

> пт, 8 мар. 2019 г., 17:22 Alexei Takaseev < alexei@taf.ru >:

> > ----- Исходное сообщение -----
> 
> > > От: "Igor Zubkov" < igor.zubkov@gmail.com >
> 
> > > Кому: "ALT Linux Sisyphus discussions" <
> > > sisyphus@lists.altlinux.org >
> 
> > > Отправлено: Четверг, 7 Март 2019 г 21:28:55
> 
> > > Тема: Re: [sisyphus] PostGIS и Postgres-ы
> 
> > >
> 
> > > On Thu, Mar 7, 2019 at 2:49 PM Alexei Takaseev < alexei@taf.ru >
> > > wrote:
> 
> > > >
> 
> > > >
> 
> > > >
> 
> > > > ----- 7 Мар 2019 г. в 20:01 Igor Zubkov igor.zubkov@gmail.com
> 
> > > > написал(а):
> 
> > > >
> 
> > > > > On Thu, Mar 7, 2019 at 6:04 AM Alexei Takaseev wrote:
> 
> > > > >> > Может и будет. Но вот в таком случае не будет работать:
> 
> > > > >> > 1. Делаем disc-upgrade
> 
> > > > >> > 2. Получаем более новый postgresql уже без -devel части
> 
> > > > >> > 3. Обновляем версию ruby через rbenv/rvm. В этот момент,
> > > > >> > pg
> 
> > > > >> > джем уже
> 
> > > > >> > не соберётся из-за того что нужного -devel пакета уже нет.
> 
> > > > >>
> 
> > > > >> Погодите. Тут свалили в кучу много странного. Сейчас
> > > > >> специально
> 
> > > > >> собрал
> 
> > > > >> PG10 c --with devel (опция специально сделана для сложных
> 
> > > > >> локальных случаев),
> 
> > > > >> поставил в систему все пакеты:
> 
> > > > >
> 
> > > > > Не надо ничего ни с чем собирать. Собрать то я могу на
> > > > > сервере,
> 
> > > > > но хочу.
> 
> > > > >
> 
> > > > > Давайте ещё раз. Если обновляется postgresql с одной большой
> 
> > > > > версии на
> 
> > > > > другую, у старой поднимается версия (alt + 1) и удаляется
> > > > > -devel
> 
> > > > > пакеты. Ну и при dist-upgrade пакеты с postgresql обновляется
> > > > > до
> 
> > > > > нового билда (который alt + 1) и сносятся -devel.
> 
> > > >
> 
> > > > Нет, не так, уже установленный в системе -devel не удаляется, я
> 
> > > > специально проверил
> 
> > > > этот момент - обновляется только клиенты библиотеки, но не сама
> 
> > > > библиотека и -devel
> 
> > > > обвязка. Просто при apt-cache list-extras они будут
> > > > отображаться
> 
> > > > как не входящие в
> 
> > > > репозиторий.
> 
> > >
> 
> > > Тот который из репозитория
> 
> > > https://packages.altlinux.org/en/sisyphus/specfiles/postgresql10
> 
> > >
> 
> > > %package -n %libpq_name-devel
> 
> > > Summary: Development shared library for %libpq_name
> 
> > > Group: Development/Databases
> 
> > > Requires: %libpq_name = %version-%release
> 
> > > Provides: libpq-devel = %version-%release
> 
> > > Conflicts: libpq-devel < %version-%release
> 
> > > Conflicts: libpq-devel > %version-%release
> 
> > > Provides: libpq%libpq_major-devel = %version-%release
> 
> > > Conflicts: libpq%libpq_major-devel < %version-%release
> 
> > > Conflicts: libpq%libpq_major-devel > %version-%release
> 
> > >
> 
> > > Этот -devel пакет удалится при dist-upgrade.
> 

> > Уже установленные пакеты, удаленные из репо, не удаляются. Я
> > специально проверил
> 
> > этот сценарий. Вот если вы попытаетесь в системе с libpq10
> > доставить
> > libpq11 то тогда да,
> 
> > все следы десятки будут вынесены.
> 

> Ну это же полная лажа. Тогда нет никакого смысла добавлять 10 и 11 к
> libpq, если нельзя их одновременно установить.

И так-то в полиси добавление soname к имени обязательством установки сразу
нескольких версий библиотеки не обременяется. Вдобавок все эти версии в именах
играют роль предохранителя, чтобы не произошло автоматического обновления
несовместимых версий. У PG нет механизма конвертации старых форматов БД в новые
при смене мажорной версии. И такое обновление пользователь должен проводить
осознанно, сам, вручную.

Re: [sisyphus] PostGIS и Postgres-ы

[Aleksey Novodvorsky]

ср, 6 мар. 2019 г. в 15:59, Игорь Андросов <blacester@gmail.com>:
>
> На что вешать? postgresql или postgis? На мой взгляд тут две проблемы:
>
> 1. postgis билдится с имеющимся devel пакетом, а предназначен для конкретной версии.
> 2. нет devel пакетов для старых версий postgresql что не позволяет собрать postgis под версии отличные от последней

На postgis, так как не работает он. Дальше мейнтейнеры разберутся.

Rgrds, Алексей

>
>
> ср, 6 мар. 2019 г. в 15:41, Aleksey Novodvorsky <a.e.nvdv@gmail.com>:
>>
>>
>>
>>
>>
>> ср, 6 марта 2019 г., 15:11 Игорь Андросов <blacester@gmail.com>:
>>>
>>> Коллеги добрый день!
>>>
>>> Я могу ошибаться, но похоже сейчас postgis пакет предназначается для postgresql 10 но собран он на postgresql 11?
>>> Вывод при попытке обновить расширение:
>>> ОШИБКА:  загрузить библиотеку "/usr/lib64/pgsql/postgis-2.5.so" не удалось: /usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3
>>
>>
>> Плохо. Пожалуйста, повесьте багу, меня в cc:
>>
>> Спасибо.
>>
>> Rgrds, Алексей
>>>
>>>
>>> [root@pgsql-srv ~]# rpm -qa |grep postg
>>> postgresql-common-1.0-alt8.noarch
>>> postgis-2.5.1-alt2.x86_64
>>> postgresql10-10.6-alt1.x86_64
>>> postgresql10-python-10.6-alt1.x86_64
>>> postgresql10-tcl-10.6-alt1.x86_64
>>> postgresql10-server-10.6-alt1.x86_64
>>> postgresql10-postgis-2.5.1-alt2.x86_64
>>> postgresql10-contrib-10.6-alt1.x86_64
>>> postgresql10-perl-10.6-alt1.x86_64
>>>
>>> [root@pgsql-srv ~]# apt-cache search postgresql |grep post|grep devel
>>> ocaml-postgresql-devel - Development files for ocaml-postgresql
>>> postgresql11-devel - PostgreSQL development header files
>>> postgresql11-devel-static - Development static library for postgresql-devel
>>>
>>> Вообще очень спорное решение билдить расширение, жестко завязанное на версию сервера, только для одной (последней мажорной) версии postgresql. При появлении новой мажорной версии postgresql происходит сборка с devel пакетом новой (так как для старых devel теперь нет), однако само расширение не переключается на новую, что ломает функционирование. Когда же происходит переключение, для старых версий postgresql расширения в репозитарии более не существует, хотя оно установлено и возможно используется.
>>>
>>> --
>>> С уважением Игорь.
>>> _______________________________________________
>>> Sisyphus mailing list
>>> Sisyphus@lists.altlinux.org
>>> https://lists.altlinux.org/mailman/listinfo/sisyphus
>>
>> _______________________________________________
>> Sisyphus mailing list
>> Sisyphus@lists.altlinux.org
>> https://lists.altlinux.org/mailman/listinfo/sisyphus
>
>
>
> --
> С уважением Игорь.
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

Добрый день!

----- Исходное сообщение -----
> От: "Aleksey Novodvorsky" <a.e.nvdv@gmail.com>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправлено: Среда, 6 Март 2019 г 21:05:14
> Тема: Re: [sisyphus] PostGIS и Postgres-ы
> 
> ср, 6 мар. 2019 г. в 15:59, Игорь Андросов <blacester@gmail.com>:
> >
> > На что вешать? postgresql или postgis? На мой взгляд тут две
> > проблемы:
> >
> > 1. postgis билдится с имеющимся devel пакетом, а предназначен для
> > конкретной версии.
> > 2. нет devel пакетов для старых версий postgresql что не позволяет
> > собрать postgis под версии отличные от последней
> 
> На postgis, так как не работает он. Дальше мейнтейнеры разберутся.

Когда в свое время подхватил оказавшимся заброшенным PG я сделал попытку
оставить в репозитории только одну ветку. Но необходимость в нескольких версиях
как раз обосновывалась требованием более старых версий пакетом postgis.

На данный момент PostGiS вполне успешно собирается под PG11. И у меня в одном месте
вроде как даже работает (там дикий проприетарный Ынтерпрайз, и как реально оно работает я
вряд ли смогу понять, но по крайней мере ничего не крашится, карты и слои рисуются, ошибки
в логи не валятся). Возможно действительно пришла пора оставить в репозитории всего две
ветки - главную самую последнюю, и дополнительную под 1С.

> 
> Rgrds, Алексей
> 
> >
> >
> > ср, 6 мар. 2019 г. в 15:41, Aleksey Novodvorsky
> > <a.e.nvdv@gmail.com>:
> >>
> >>
> >>
> >>
> >>
> >> ср, 6 марта 2019 г., 15:11 Игорь Андросов <blacester@gmail.com>:
> >>>
> >>> Коллеги добрый день!
> >>>
> >>> Я могу ошибаться, но похоже сейчас postgis пакет предназначается
> >>> для postgresql 10 но собран он на postgresql 11?
> >>> Вывод при попытке обновить расширение:
> >>> ОШИБКА:  загрузить библиотеку "/usr/lib64/pgsql/postgis-2.5.so"
> >>> не удалось: /usr/lib64/pgsql/postgis-2.5.so: undefined symbol:
> >>> SearchSysCache3
> >>
> >>
> >> Плохо. Пожалуйста, повесьте багу, меня в cc:
> >>
> >> Спасибо.
> >>
> >> Rgrds, Алексей
> >>>
> >>>
> >>> [root@pgsql-srv ~]# rpm -qa |grep postg
> >>> postgresql-common-1.0-alt8.noarch
> >>> postgis-2.5.1-alt2.x86_64
> >>> postgresql10-10.6-alt1.x86_64
> >>> postgresql10-python-10.6-alt1.x86_64
> >>> postgresql10-tcl-10.6-alt1.x86_64
> >>> postgresql10-server-10.6-alt1.x86_64
> >>> postgresql10-postgis-2.5.1-alt2.x86_64
> >>> postgresql10-contrib-10.6-alt1.x86_64
> >>> postgresql10-perl-10.6-alt1.x86_64
> >>>
> >>> [root@pgsql-srv ~]# apt-cache search postgresql |grep post|grep
> >>> devel
> >>> ocaml-postgresql-devel - Development files for ocaml-postgresql
> >>> postgresql11-devel - PostgreSQL development header files
> >>> postgresql11-devel-static - Development static library for
> >>> postgresql-devel
> >>>
> >>> Вообще очень спорное решение билдить расширение, жестко
> >>> завязанное на версию сервера, только для одной (последней
> >>> мажорной) версии postgresql. При появлении новой мажорной версии
> >>> postgresql происходит сборка с devel пакетом новой (так как для
> >>> старых devel теперь нет), однако само расширение не
> >>> переключается на новую, что ломает функционирование. Когда же
> >>> происходит переключение, для старых версий postgresql расширения
> >>> в репозитарии более не существует, хотя оно установлено и
> >>> возможно используется.
> >>>
> >>> --
> >>> С уважением Игорь.
> >>> _______________________________________________
> >>> Sisyphus mailing list
> >>> Sisyphus@lists.altlinux.org
> >>> https://lists.altlinux.org/mailman/listinfo/sisyphus
> >>
> >> _______________________________________________
> >> Sisyphus mailing list
> >> Sisyphus@lists.altlinux.org
> >> https://lists.altlinux.org/mailman/listinfo/sisyphus
> >
> >
> >
> > --
> > С уважением Игорь.
> > _______________________________________________
> > Sisyphus mailing list
> > Sisyphus@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/sisyphus
> _______________________________________________
> Sisyphus mailing list
> Sisyphus@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/sisyphus

Re: [sisyphus] PostGIS и Postgres-ы

[Alexei Takaseev]

----- Исходное сообщение ----- 

> От: "Игорь Андросов" <blacester@gmail.com>
> Кому: "ALT Linux Sisyphus discussions" <sisyphus@lists.altlinux.org>
> Отправлено: Четверг, 7 Март 2019 г 16:03:57
> Тема: Re: [sisyphus] PostGIS и Postgres-ы

> Необходимость нескольких версий, на мой взгляд, обосновывается тем
> что:
> 1. Базы PG бинарно не совместимы между мажорными версиями. (Для
> переезда на новую версию нужно сделать определенные телодвижения,
> особенно приятно когда перестает работать расширение и забакапить
> базу становиться невозможным, в результате для переезда приходится
> билдит сначала нужный postgres с devel, потом postgis для старой и
> новой версии (сейчас для 11 версии postgis нет), бакапить базу,
> ставить новую версию подымать)

Что поделать, разработчики PG не считают нужным встраивать автоматическую
конвертилку форматов (pg_upgrade таковой считать нельзя, это банальное
dump/restore), и в процессе обновления между мажорными версиями полагаются на
квалификацию DBA.

> 2. Не всегда и весь не софт поддерживает новую мажорную версию.
> (Пример - ArcGIS которому для работы на Postgres требуется
> собственное расширение, которое жестко зависит от мажорной версии, и
> обычно отстает на 2-3 версии, текущая последняя - 9.5.3, про
> минорные сейчас не помню прибиты ли гвоздями или нет).
> 3. Есть уже работающие решения, смена Postgres на которых может
> оказаться проблемой по некоторым, не всегда техническим, причинам.

Специально для такого случая оставлена возможность собрать PG нужной ветки
с -devel пакетами - достаточно указать в параметрах rpmbuild "--with devel"
Естественно это решения исключительно для пападанцев с капризным софтом. Собственно,
именно так мне и пришлось сделать, чтобы запустить связку сервеного расширения postgis 2.5.1
и PG11 на бранче P8, где официальный -devel предоставляет версия 9.6.
И да, это придется сделать самому пользователю ArcGIS хотя бы потому, что это ПО не входит
в состав пакетной базы Сизифа/бранчей, разводить бардак из-за неопределенных хотелок
неопределенного набора неизвестного софта это не совсем правильная мысль.

> Исходя из этого - оставлять только одну, последнюю, версию (под 1С
> считаю не относящуюся к данному вопросу) мне видится не правильным,
> это может сильно ограничивать взаимодействие с другим софтом и
> приходится либо брать другой дистрибутив, либо заниматься сборкой
> нужного окружения.

Адаптацией клиентского софта под системное окружение это одна из задач
майнтайнера пакета. Возможно требование наличия именно версии 9.5 вызвано
не чем-то глубинным (к примеру портянка специфичных патчей 1С для серверной
части), что есть только в ветке 9.5, а просто корявым синтаксисом  скриптах, как
это было с postgis, где сидение на 9.6 происходило из-за использования
объявленного как deprecate еще во времена 9.1 скрипта createlang вместо
конструкции CREATE EXTENSION

> Если взять нелюбимый мной, но многими используемый CentOS - у них в
> репе вроде одна версия postgresql, однако, сборку других версий
> (включая postgis) под него обеспечивает сам Postgres, кроме того,
> если правильно помню, обеспечивает возможность использовать
> несколько разных версий одновременно.

К сожалению, CentOS тут не может быть примером по причине того, что там
постгрес вообще версии 9.2 и он там единственный.

В вашем случае достаточно откатиться до последней работавшей у вас версии postgis на PG10,
поставить пакеты на холд и дождаться выкатки postgis собранного под PG-11. Далее снять бэкап базы
черз pg_dump -Fc bla-bla и далее провести апгрейд базы по инструкции
http://postgis.net/docs/manual-2.5/postgis_installation.html#upgrading пункт 2.10.2 Hard upgrade

Возможно мантайнеру postgis стоит учесть момент, что обновления postgis вида 2.4.x -> 2.5.x не совместимы
и замещение по dist-upgrade может привести к развалу.

Re: [sisyphus] PostGIS и Postgres-ы

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 696 bytes --]

On Wed, Mar 06, 2019 at 03:11:01PM +0300, Игорь Андросов wrote:
> Коллеги добрый день!
> 
> Я могу ошибаться, но похоже сейчас postgis пакет предназначается для
> postgresql 10 но собран он на postgresql 11?
> Вывод при попытке обновить расширение:
> ОШИБКА:  загрузить библиотеку "/usr/lib64/pgsql/postgis-2.5.so" не удалось:
> /usr/lib64/pgsql/postgis-2.5.so: undefined symbol: SearchSysCache3

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

Если бы мантейнер просто указал бы в спек-файле
%set_verify_elf_method strict
то пакет бы просто не собрался.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]