uwsgi: recreate uwsgi-python3-plugin after upgrading python #14060
Conversation
|
Any idea how to prevent this in the future? Wonder if the python module suffer of the same problem. |
|
Hmm, not really; the only solution I have in mind, is to version it (uwsgi-python38-plugin and uwsgi-python39-plugin), but I am not sure if this is a good thing. I will look if I find another solution ... |
|
A hint should be how the python module handle the version. |
|
Interesting buildbot failure... I don't experience it locally but @pprindeville does. ping @jefferyto |
|
Please rebase to remove those red checkmarks. |
Else it would link to libpython3.8.so.1.0 Signed-off-by: Peter Stadler <peter.stadler@student.uibk.ac.at>
|
Rebased, thank you for the fix :-) I am not sure if we need this change: in the package system |
|
I think this issue still exists for most/all Python packages, although it would only affect master and not release branches, since release branches will stay on the same 3.x version of Python. Python-dependent packages may be rebuilt by buildbots, but opkg on users' systems will not know to reinstall them after a Python upgrade like 3.8 to 3.9. In this case it is a change from libpython3.8 to libpython3.9, but even for "plain" Python packages, their install path changes from I think this may be a good case for adding |
|
ABI_VERSION in Python3 sounds like a good idea |
|
Sounds like this can be closed? |
|
if ABI_VERSION will fix this, then sure; |
Related to discussion: openwrt#14060 Every once in a while a version bump will occur that requires an ABI change. Example: Python 3.8 to 3.9. When this happens some Python packages would need to be rebuilt especially if they are linking against the shared binary libraries. To do this, we add an ABI_VERSION option in Python3's Makefile. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
|
created PR; i can see that i would forget about this PR [again] :p [edit] referencing other PR: #14237 |
@neheb I do? What's the context? |
|
AFAIK it was some issue that is now fixed. I don't remember the details. |
|
I am closing this PR as the other one will solve it in the right and broader way (it is not merged, so technically the problem is still open, but I think it is enough to have one PR for it) ... |
Related to discussion: openwrt#14060 Every once in a while a version bump will occur that requires an ABI change. Example: Python 3.8 to 3.9. When this happens some Python packages would need to be rebuilt. In setups where everything gets rebuilt, this isn't a problem. It's usually a bigger problem when needing to upgrade something via opkg. To accommodate for this, we add a libpython with it's own ABI_VERSION flag. If this ABI_VERSION changes, then this should propagate forward. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Related to discussion: openwrt#14060 Every once in a while a version bump will occur that requires an ABI change. Example: Python 3.8 to 3.9. When this happens some Python packages would need to be rebuilt. In setups where everything gets rebuilt, this isn't a problem. It's usually a bigger problem when needing to upgrade something via opkg. To accommodate for this, we add a libpython with it's own ABI_VERSION flag. If this ABI_VERSION changes, then this should propagate forward. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Related to discussion: openwrt#14060 Every once in a while a version bump will occur that requires an ABI change. Example: Python 3.8 to 3.9. When this happens some Python packages would need to be rebuilt. In setups where everything gets rebuilt, this isn't a problem. It's usually a bigger problem when needing to upgrade something via opkg. To accommodate for this, we add a libpython with it's own ABI_VERSION flag. If this ABI_VERSION changes, then this should propagate forward. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
Related to discussion: openwrt/packages#14060 Every once in a while a version bump will occur that requires an ABI change. Example: Python 3.8 to 3.9. When this happens some Python packages would need to be rebuilt. In setups where everything gets rebuilt, this isn't a problem. It's usually a bigger problem when needing to upgrade something via opkg. To accommodate for this, we add a libpython with it's own ABI_VERSION flag. If this ABI_VERSION changes, then this should propagate forward. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com> Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
Related to discussion: #14060 Every once in a while a version bump will occur that requires an ABI change. Example: Python 3.8 to 3.9. When this happens some Python packages would need to be rebuilt. In setups where everything gets rebuilt, this isn't a problem. It's usually a bigger problem when needing to upgrade something via opkg. To accommodate for this, we add a libpython with it's own ABI_VERSION flag. If this ABI_VERSION changes, then this should propagate forward. Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com> (cherry picked from commit 27aee1f)
|
Now that #14237 is merged, perhaps it would help to have uwsgi-python3-plugin depend on libpython3? |
Maintainer: @Ansuel
Compile tested: x86_64, x86_64 qemu, master
Run tested: x86_64, x86_64 qemu, master, run etesync-server
Description: Create new version of uwsgi-python3-plugin that is linked to libpython3.9 instead of 3.8.