public inbox for [email protected]  

help / color / mirror / Atom feed

(no subject)
3+ messages / 2 participants
[nested] [flat]

* (no subject)
@ 2023-10-19 17:51 Guillaume Lelarge <[email protected]>
  2023-10-20 06:59 ` Re: Devrim Gündüz <[email protected]>
  0 siblings, 1 reply; 3+ messages in thread

From: Guillaume Lelarge @ 2023-10-19 17:51 UTC (permalink / raw)
  To: pgsql-pkg-yum

--000000000000ca5d78060815675f
Content-Type: text/plain; charset="UTF-8"

Hello,



^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re:
  2023-10-19 17:51 (no subject) Guillaume Lelarge <[email protected]>
@ 2023-10-20 06:59 ` Devrim Gündüz <[email protected]>
  2023-10-20 12:43   ` Re: Guillaume Lelarge <[email protected]>
  0 siblings, 1 reply; 3+ messages in thread

From: Devrim Gündüz @ 2023-10-20 06:59 UTC (permalink / raw)
  To: Guillaume Lelarge <[email protected]>; pgsql-pkg-yum

Hi Guillaume,

On Thu, 2023-10-19 at 19:51 +0200, Guillaume Lelarge wrote:
> From rpm/redhat/15/postgresql-15/EL-9/postgresql-15.spec (and many
> other
> postgresql .spec files):
> 
> # These file(s) should not be packaged:
> 
> %{__rm} %{buildroot}%{pgbaseinstdir}/lib/libpgfeutils.a
> 
> I'm wondering why this library shouldn't be packaged? It is definitely
> useful for front-end clients.

This is per Fedora packaging guidelines:

https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries

...though it is a "should not" item. OTOH, the same guideline if we says
we need to split those files under  -static subpackage, which we don't
ship right now.

Just took a look at Fedora spec file, and they already ship these files
in -static subpackage (we ship them with -devel subpackage as of now)

libpgcommon.a
libpgcommon_shlib.a
libpgport.a
libpgport_shlib.a

but not libpgfeutils.a

Regards,
-- 
Devrim Gündüz
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR





^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re:
  2023-10-19 17:51 (no subject) Guillaume Lelarge <[email protected]>
  2023-10-20 06:59 ` Re: Devrim Gündüz <[email protected]>
@ 2023-10-20 12:43   ` Guillaume Lelarge <[email protected]>
  0 siblings, 0 replies; 3+ messages in thread

From: Guillaume Lelarge @ 2023-10-20 12:43 UTC (permalink / raw)
  To: Devrim Gündüz <[email protected]>; +Cc: pgsql-pkg-yum

Hi Devrim,

First, sorry for the email with no subject. I guess I was in a hurry :)

Le ven. 20 oct. 2023 à 08:59, Devrim Gündüz <[email protected]> a écrit :

> Hi Guillaume,
>
> On Thu, 2023-10-19 at 19:51 +0200, Guillaume Lelarge wrote:
> > From rpm/redhat/15/postgresql-15/EL-9/postgresql-15.spec (and many
> > other
> > postgresql .spec files):
> >
> > # These file(s) should not be packaged:
> >
> > %{__rm} %{buildroot}%{pgbaseinstdir}/lib/libpgfeutils.a
> >
> > I'm wondering why this library shouldn't be packaged? It is definitely
> > useful for front-end clients.
>
> This is per Fedora packaging guidelines:
>
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-static-libraries
>
> ...though it is a "should not" item. OTOH, the same guideline if we says
> we need to split those files under  -static subpackage, which we don't
> ship right now.
>
>
OK, I guess it makes sense.


> Just took a look at Fedora spec file, and they already ship these files
> in -static subpackage (we ship them with -devel subpackage as of now)
>
> libpgcommon.a
> libpgcommon_shlib.a
> libpgport.a
> libpgport_shlib.a
>
> but not libpgfeutils.a
>
>
Yeah, I saw that. I stll don't get why we ship libpgcommon static library,
but not libpgutils.


-- 
Guillaume.


^ permalink  raw  reply  [nested|flat] 3+ messages in thread

end of thread, other threads:[~2023-10-20 12:43 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2023-10-19 17:51  Guillaume Lelarge <[email protected]>
2023-10-20 06:59 ` Re: Devrim Gündüz <[email protected]>
2023-10-20 12:43   ` Re: Guillaume Lelarge <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox