Package Details: python310 3.10.16-1

Git Clone URL: https://aur.archlinux.org/python310.git (read-only, click to copy)
Package Base: python310
Description: Next generation of the python high-level scripting language, version 3.10
Upstream URL: https://www.python.org/
Licenses: custom
Provides: python
Submitter: soh
Maintainer: soh
Last Packager: soh
Votes: 19
Popularity: 0.146682
First Submitted: 2023-05-04 00:47 (UTC)
Last Updated: 2024-12-27 14:17 (UTC)

Dependencies (20)

Required by (13282)

Sources (1)

Latest Comments

1 2 3 4 Next › Last »

soh commented on 2024-12-27 14:31 (UTC)

@maxpayne3 Yes. Then you need to run updpkgsums and perhaps makepkg --printsrcinfo > .SRCINFO

soh commented on 2024-12-27 14:28 (UTC)

@kIERO Sorry for the delay. I recently find using miniconda to manage different versions of Python quite handy. Although installing python from AUR is still useful, as it enables different users to use that without installing for themselves another time.

kIERO commented on 2024-12-10 21:43 (UTC)

It is gonna be two months since this package is flagged out-of-date

This should be updated

maxpayne3 commented on 2024-10-30 18:46 (UTC)

For python 3.10.15, it's just a matter of changing the URL and the sha256sums, right?

Shadowphoenix commented on 2024-05-28 23:23 (UTC) (edited on 2024-05-28 23:26 (UTC) by Shadowphoenix)

@MarsSeed not to be that kinda guy but if you blindly install and then uninstall stuff that is running on your PC thats kinda sorta your own fault if stuff breaks. Yes, the way this is currently handled is not ideal, something similar to how you can have separate versions of OpenJDK would be preferable, but certain scripts that i might want to run dont run in Python 3.12 so i might need to run 3.10 or 3.11 so outright barring me from installing them via pacman/makepkg seems EH to me so i dont see why you want to delete the packages alltogether from what i understand.

As mentioned by others: if you run buildscripts from the AUR or by extension scripts and programs provided by any Third Party, it is your responsibility to make sure your system works after having run whatever you were trying to do.

HLFH commented on 2024-05-03 12:29 (UTC)

Fixed with:

rm -rf /tmp/makepkg/python310

HLFH commented on 2024-05-03 12:10 (UTC)

Getting the error:

lto1: erreur fatale: le flux bytecode dans le fichier « Parser/token.o » a été généré par la version 13.0 de LTO au lieu de la version 13.1 attendue compilation terminée. lto-wrapper: erreur fatale: gcc a retourné 1 comme valeur de sortie compilation terminée. /usr/bin/ld : erreur : lto-wrapper failed collect2: erreur: ld a retourné le statut de sortie 1 ln: impossible d'accéder à 'libpython3.10.so.1.0': Aucun fichier ou dossier de ce nom make[1]: *** [Makefile:655: libpython3.10.so] Error 1 make[1] : on quitte le répertoire « /tmp/makepkg/python310/src/Python-3.10.14 » make: *** [Makefile:545: profile-opt] Error 2 ==> ERREUR : Une erreur s’est produite dans build(). Abandon…

La commande 'sudo --user=#1000 --preserve-env=EDITOR -- makepkg --force' a échoué.

MarsSeed commented on 2024-04-28 18:01 (UTC)

And to further @yan12125's point, it is a problem if the user installs 'python310' and then easily uninstalls 'python', without pacman throwing a fit about it.

Then the user is left with all of their python3.12 dependent installed packes broken during runtime.

yan12125 commented on 2024-04-28 17:45 (UTC)

The PKGBUIKLD of python library that install files inside /usr/lib/python3.XX/site-packages/ such as python-numpy should have something like depends=('python==3.XX').

This is not good. It makes rebuilding Python libraries for newer Python versions much more time-consuming.

Also, provides= does not actually bring obvious benefit. In https://aur.archlinux.org/packages/python310?O=10#comment-937519 you mentioned:

As for whether it is a drop-in replacement, in some sense, it is. It will give users great flexibility to rebuild all python-related packages against this specific version as long as there is no compatibility issues.

It is not a drop-in replacement if users need to rebuild packages. In other words, this package does not provide the feature of core/python. Moreover, I don't find it reasonable to build all Python-related packages against older Python.

In conclusion, I believe that there's no problem to retain the provides=("python=$pkgver") line in PKGBUILD.

There is a problem: pacman says that several other packages optionally depend on this package when I remove this. That is confusing and technically wrong.

soh commented on 2024-04-28 13:13 (UTC)

@rammiah Thanks. I've updated with PKGBUILD with ./configure ax_cv_c_float_words_bigendian=no.

1 2 3 4 Next › Last »