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