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.132433
First Submitted: 2023-05-04 00:47 (UTC)
Last Updated: 2024-12-27 14:17 (UTC)

Dependencies (20)

Required by (13309)

Sources (1)

Latest Comments

« First ‹ Previous 1 2 3 4 Next › Last »

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.

soh commented on 2024-03-25 12:20 (UTC) (edited on 2024-03-25 12:21 (UTC) by soh)

@rammiah Hello, but I don't meet this error. Which CPU architecture do you use? I guess you are on non-x86_64?

rammiah commented on 2024-02-20 12:11 (UTC)

I met an error while upgrading: 

configure: error:

Unknown float word ordering. You need to manually preset
ax_cv_c_float_words_bigendian=no (or yes) according to your system.

python312 fixed this by 

  ./configure ax_cv_c_float_words_bigendian=no \

soh commented on 2024-02-17 11:42 (UTC)

@segFaultCreator Thanks, I've made such modifications.

soh commented on 2024-02-17 11:41 (UTC)

@TiD91 I simply follow suit of the official python package: https://gitlab.archlinux.org/archlinux/packaging/packages/python/-/blob/main/PKGBUILD?ref_type=heads#L66

segFaultCreator commented on 2024-02-17 08:04 (UTC) (edited on 2024-02-17 08:05 (UTC) by segFaultCreator)

Hey, you can remove xorg-server-xvfb ttf-font dependencies and rempalce the last two lines of the build section by make EXTRA_CFLAGS="$CFLAGS".

Also, you can keep the signature A035C8C19219BA821ECEA86B64E628F8D684696D only as python 3.10 are signed with this one only.

I had to remove the {,.asc} from the source (inspired from the python-39 package), and it finally builds.

TiD91 commented on 2024-01-21 19:24 (UTC)

Why this needs to run xvfb-run?

This doesn't work on my WSL2.

MarsSeed commented on 2023-11-07 14:53 (UTC)

Anyhow, for now, please kindly remove 'python' from provides, just like in other python3* packages that are maintained by @rixx.

See reasoning behind the necessity of this in the comments on python38 page.

MarsSeed commented on 2023-11-07 14:49 (UTC) (edited on 2023-11-07 15:02 (UTC) by MarsSeed)

extra/gcc12 is not for gcc v1.2 but for v12. So that is an example in favor of my point for renaming this package to python3.x or python-3.x.

Originally, I suggested python-3.x, but maybe it would be best to use the python3.x pgkname format, in case other modules would need to be created.

I think the latter would lead to a more immediately recognizable grouping of what name part belongs to where. E.g.:

  • python3.8
  • python3.10
  • python3.13-setuptools
  • python3.8-setuptools57 (python v3.8, setuptools v57)
  • python3.9-pillow9.5 (python v3.9, pillow v9.5)

(Edit: adjusted examples and added two more)

« First ‹ Previous 1 2 3 4 Next › Last »