Re: Splitting libpq into a separate package

Hi Devrim,

On Tue, Apr 16, 2019 at 5:40 PM Devrim Gündüz <devrim(at)gunduz(dot)org> wrote:

>
> Hi,
>
> I actually tried to avoid $SUBJECT in the past, but I think now we must do
> it,
> per this thread:
>
>
> https://www.postgresql.org/message-id/CAB5R%3D3wq50SB5%3DdVgYD0uu%3DepCvvx4arxiTMbikNcY29q4wHLA%40mail.gmail.com
>
> and:
>
>
> https://www.postgresql.org/message-id/CAAQZgJzg7tGaq6HuTRUP5hqz-jQQQJ-ja9cKJy4Wtob4o8taBg%40mail.gmail.com
>
> As a side note, Fedora already removed postgresql-libs, and added libpq5
> recently as well.
>
> So, the questions are:
>
> * Should I do it for v12 only, or go ahead and replace -libs subpackages
> with
> the new libpq package in the existing releases, too? I'm inclined to go
> with
> the latter. The packages will just "Obsolete" the existing -libs
> subpackages,
> provide "postgresqlXY-libs", so should not be a problem.
>
> * Debian folks use libpq5 as the package name. I can stick with that. Any
> objections?
>
> FWIW, this will first go into our testing repos (that everyone can
> access), and
> we will do tests before it goes into prod.
>

There is potentially an alternative solution that I'd like to propose as a
workaround to clear the current architectural hurdles.
In my opinion, the below proposal could be a potentially less invasive
solution than splitting out libpq in a rush, but I'll let others comment as
to their thoughts.

With that said, would it make sense to split a handful of packages such as
python-psycopg2 into 5 separate packages?
e.g. it would look like this:

- python2-psycopg2_95
- python2-psycopg2_96
- python2-psycopg2_10
- etc...

It should be an easy enough change to the specfile.

Along with such a change, any specfile with a Requires: or BuildRequires:
would change too, such as:
Requires: python-psycopg2
becoming:
Requires: python-psycopg2_%{pgmajorversion}

Of course, dashes/underscores/formatting would be up to you.

The other impacted package that I'm aware of is gdal, which could become
gdal95/gdal96, etc.
There may be more, but those are the 2 I'm most aware of. I don't think it
would be many packages at all-- just a handful if that.

Such a move would ensure that every package stays in its own swim lane even
with the consolidated repo-spec-file.

Would this be something that could be considered as a potential
alternative, or are there any drawbacks that I'm potentially not taking
into account (which is possible)?

Regards,
-John