Re: Providing libpq explicitly

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Providing libpq explicitly
Дата
Msg-id CAMsr+YHGpXA5OYi-V2t82vt58+KuuKy-wy+1hjrtWirSH6RL4g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Providing libpq explicitly  (Devrim Gündüz <devrim@gunduz.org>)
Ответы Re: Providing libpq explicitly  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Список pgsql-pkg-yum
On 11 October 2016 at 15:13, Devrim Gündüz <devrim@gunduz.org> wrote:
> On Mon, 2016-10-10 at 21:59 -0400, Peter Eisentraut wrote:
>> What is an example of such a package?
>
> One of EDB packages. It uses functions exported by the libpq of 9.1+.

I see, and you don't want to depend on postgresql9x-libs because you
want to allow install against any postgresql9x-libs that installs a
libpq. It's a binary distribution issue. Fair enough.

You could have alternatives listed in Requires, but that requires
enumerating all postgresql9x variants into the future, which is messy
and fragile.

What should IMO be done here is to add a version on the Provides:
postgresq-llibs that already exists:


$ rpm -q --provides postgresql96-libs
config(postgresql96-libs) = 9.6beta3-1PGDG.f23
libecpg.so.6()(64bit)
libecpg_compat.so.3()(64bit)
libpgtypes.so.3()(64bit)
libpq.so.5()(64bit)
libpqwalreceiver.so()(64bit)
postgresql-libs
postgresql96-libs = 9.6beta3-1PGDG.f23
postgresql96-libs(x86-64) = 9.6beta3-1PGDG.f23


I think it's also fine to have a  versioned

Provides: libpq

but *not* Provides: libpq.so, because that should be rpm autodeps job.
That's likely why I asked for its removal originally; as I said I just
don't remember anymore.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-pkg-yum по дате отправления:

Предыдущее
От: Devrim Gündüz
Дата:
Сообщение: Re: Providing libpq explicitly
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Providing libpq explicitly