Package Details: python310 3.10.14-2

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: 20
Popularity: 0.48
First Submitted: 2023-05-04 00:47 (UTC)
Last Updated: 2024-04-28 13:19 (UTC)

Dependencies (20)

Required by (13117)

Sources (1)

Latest Comments

1 2 3 4 Next › Last »

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.

soh commented on 2024-04-28 12:43 (UTC) (edited on 2024-04-28 13:21 (UTC) by soh)

@MarsSeed I've noticed that you've submitted a deletion request for https://aur.archlinux.org/packages/python311. Why don't you also submit one for this python310 package?

After searching 'MarsSeed archlinux' on Google, I think you are a troll, and your account should be kept suspended: https://lists.archlinux.org/hyperkitty/list/aur-general@lists.archlinux.org/thread/GOOJIO56E2GGTBPF4FHTYXSUKPBJ3BIQ/

First, do scroll to the end of the page and read it twice:

AUR packages are user produced content. Any use of the provided files is at your own risk.

Your reason for deletion is:

This package can break Arch Linux because it says it provides python, but that allows the user to uninstall Arch/core/python, rendering all 'python-' packages defunct.

I fully understand the exposition that @FabioLolix has made and the question-answer-style proof you've made under python38. I've also read https://wiki.archlinux.org/title/PKGBUILD#provides for several times.

Here are my arguments:

  1. The reason that you break your Arch is not because you installed this AUR package, but because you mistakenly uninstall the official python package that provides the version your other packages depend on.

  2. 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').

  3. You use AUR at your own risk. Let's take pacman as an example. As we all know, partial upgrades are not supported, but that doesn't mean you cannot run pacman -Sy <package>. PKGBUILD is so flexible, and you should adapt it according to your needs, not blindingly use makepkg -si to install it. My PKDBUILD files contains no malware/backdoor, so you shouldn't bother being too helpful to submit a deletion request.

BTW, some user once complained that you had submitted a deletion request for the kernel for the device he/him is running: https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/message/EX6VGRHLV5IDKXLGKF4MUTZDB33RCFBF/ (The aurweb software should have more sophisticated mechanism and more moderators to fight spam!)

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

rammiah commented on 2024-03-25 12:52 (UTC)

@soh Thanks for your reply, I have changed to pyenv to manage my python versions, I use a x86_64, amd 6900hx.

1 2 3 4 Next › Last »