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