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