Bug 1571215 - postgresql: postgresql-upgrade requires both Python 2 and Python 3
Summary: postgresql: postgresql-upgrade requires both Python 2 and Python 3
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Pavel Raiskup
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PYTHON3 PYTHON3-PYTHON2
TreeView+ depends on / blocked
 
Reported: 2018-04-24 10:42 UTC by Iryna Shcherbina
Modified: 2018-04-24 14:16 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-24 11:09:13 UTC


Attachments (Terms of Use)

Description Iryna Shcherbina 2018-04-24 10:42:01 UTC
The postgresql-upgrade RPM requires both Python 2 and Python 3.

$ dnf repoquery --repo=rawhide --requires postgresql-upgrade | grep python
libpython2.7.so.1.0
libpython2.7.so.1.0()(64bit)
libpython3.6m.so.1.0
libpython3.6m.so.1.0()(64bit)

Except in very special circumstances, there is no need for one package
to drag in both Python stacks. Is this intended for this package or can it be fixed by splitting the package, or removing the stray dependencies?


It's ok to do this in Rawhide only, however, it would be greatly
appreciated if you could push it to Fedora 28 as well.

If anything is unclear, or if you need any kind of assistance, you can
ask on IRC (#fedora-python on Freenode), or reply here. We'll be happy
to help investigating or fixing this issue!

Comment 1 Pavel Raiskup 2018-04-24 11:09:13 UTC
(In reply to Iryna Shcherbina from comment #0)
> Except in very special circumstances, there is no need for one package
> to drag in both Python stacks. Is this intended for this package or can it
> be fixed by splitting the package, or removing the stray dependencies?

The plpython2.so file has been packaged recently in bug 1557490.  It's
intentional to have the plugin packaged plpython2.so also in
postgresql-upgrade (not only in postgresql-plpython2).

As long as (some) Python 2 will be in Fedora, I see no immediate need to
drop python 2 support in plypython.

Comment 2 Miro Hrončok 2018-04-24 11:35:19 UTC
Pavel, could you please provide more information? I've read the linked bug and links in it, yet it says nothing about python and I lack context to understand this.

Could you please explain to me why a dependency on multiple Pythons is desired here? I.e.:

What happens if it only depends on Python 3? What user actions stop working?

What happens if it only depends on Python 2? What user actions stop working?

Comment 3 Pavel Raiskup 2018-04-24 11:46:29 UTC
We normally provide plpython2.so (postgresql-plpython2) and plpython3.so
(in postgresql-plpython3).  Those modules are both built against different
python runtimes.

To make the pg_upgrade (postgresql-setup --upgrade) work on Fedora 28
(when user upgraded from F26 and F27) it is best to have the same set
of server modules in postgresql-upgrade package as were available in
all subpackages on the previous server versions.

Anyways, as I said -- there's no reason not to drop python2 support in
Fedora's PostgreSQL package ... I have no problem to take care of that.
And we really need to first discuss with PostgreSQL upstream future steps
regarding plpython:
https://www.postgresql.org/message-id/3775251.2SzJCDjjet%40nb.usersys.redhat.com

Comment 4 Miro Hrončok 2018-04-24 12:31:09 UTC
Shouldn't then postgresql-upgrade require postgresql-plpython2 and postgresql-plpython3 instead of shipping the so files? (Just curious.)

I'll block postgresql-upgrade from taskotron-python-versions required Python version check, ok?

https://github.com/fedora-python/taskotron-python-versions/pull/60

Comment 5 Tom Lane 2018-04-24 14:05:46 UTC
(In reply to Miro Hrončok from comment #4)
> Shouldn't then postgresql-upgrade require postgresql-plpython2 and
> postgresql-plpython3 instead of shipping the so files? (Just curious.)

No; that would suck in the modules for the *current* server version, whereas what the upgrade package needs to contain is the modules for the *previous* version.

Comment 6 Miro Hrončok 2018-04-24 14:16:36 UTC
(In reply to Tom Lane from comment #5)
> No; that would suck in the modules for the *current* server version, whereas
> what the upgrade package needs to contain is the modules for the *previous*
> version.

Understood. Pavel, Tom, thank you both.


Note You need to log in before you can comment on or make changes to this bug.