16

I tried following this guide to install Python 3.10 on my system. I ran the commands to add the PPA, did an apt update, and then ran apt install python3.10.

I was very surprised when I was handed this message:

Note, selecting 'postgresql-plpython3-10' for regex 'python3.10'
The following additional packages will be installed:
  postgresql-10 postgresql-client-10 postgresql-client-common postgresql-common
Suggested packages:
  locales-all postgresql-doc-10
The following NEW packages will be installed:
  postgresql-10 postgresql-client-10 postgresql-client-common postgresql-common postgresql-plpython3-10
0 upgraded, 5 newly installed, 0 to remove and 60 not upgraded.
Need to get 4,958 kB of archives.
After this operation, 19.4 MB of additional disk space will be used.

I later realised it's because my internet temporarily dropped while adding the PPA, and the operation subsequently failed. Adding the PPA resolved the issue, and I was now given the correct option:

The following NEW packages will be installed:
  libpython3.10-minimal libpython3.10-stdlib python3.10 python3.10-minimal

I was caught off guard by how different the results were. Given that I've at this point spend over 50% of my life running Linux distros, being caught off guard by something like this feels pretty grim. Running the exact same command, I'm no longer offered Postgres. I'm very concerned it even offered Postgres in the first place. I've helped friends with Ubuntu installs in the past, and walls of text confuse and bewilder them until they gain experience. I can imagine someone ending up with an unsecured untouched DB running on their system waiting to be used as an attack vector.

My questions are:

  • Why does apt try hold my hand instead of simply saying "This does not exist"? (I mean, I get it, regex match, but why blindly use regex? I've not noticed it mention regex before unless I added something like *)
  • Can I disable this behaviour?
1
  • 1
    Wow, this behavior is just wrong. Trying to be too fancy leads to unexpected behavior and worse, security vulnerabilities...If there is to be a command taking regexes, it should be distinct (a search command, for example) and should allow the user to pick from the results instead of installing automatically. Oct 6, 2022 at 16:58

2 Answers 2

24

Seems you were quite unlucky in this specific instance because the "." in "python3.10" triggered apt to interpret it as a regular expression, then it was interpreted as a stand in for "any character" and this therefore matched "postgresql-plpython3-10", and didn't match "python3.10" as that package was temporarily not available.

In this case using 'python3\.10' would have worked around this situation, as would just canceling when apt told you what it had selected and asked if you wanted to proceed.

It looks like you can't turn off apt's support for regex when specifying package names, other than not to use special characters (or escape them if you do).

apt-get has this behavior as well, and aptitude supports its own expression syntax.

One part of why this went wrong is that Ubuntu had a package with a "." in its name, which is valid but that character also happens to be one that triggers a package name being interpreted as a regular expression.

3
  • 8
    That really seems like a problem just waiting to happen. Why isn't there a flag to enable regex, with the default being off?
    – wjandrea
    Oct 5, 2022 at 18:22
  • 3
    "One part of why this went wrong is that Ubuntu had a package with a "." in its name" I don't think that's Ubuntu's doing. IIRC, python 3.10 is installed from an external PPA.
    – Arthur
    Oct 6, 2022 at 7:20
  • 1
    Periods are explicitly allowed in package names by Debian policy which I believe Ubuntu inherits. I think that's the bigger issue here, though YMMV. At any rate it's nothing new as the behavior dates back to the first days of apt-get in around 1998. Oct 8, 2022 at 11:06
1

As of June 6, 2023, the workaround specified in the accepted answer will no longer be possible on Ubuntu 18 systems.

https://github.com/deadsnakes/issues/issues/251

The maintainers of deadsnakes have decided to delete all Ubuntu 18 packages, versus simply letting them exist as-is while not offering new ones. It's a disappointing decision, because Ubuntu 18 is still in ESM support, and all existing updates for base packages up thru May 31 can still be downloaded and applied as normal. It's just that new security updates require a paid ESM subscription. Not so with deadsnakes.

6
  • 2
    ubuntu.com/pro -> "Free for personal use", and ubuntu.com/security/esm - "now included in Ubuntu Pro"
    – Hannu
    Jun 6, 2023 at 19:01
  • @Hannu Good point. ESM doesn't even require a paid subscription for personal use
    – Jon
    Jun 6, 2023 at 19:26
  • It is mentioned that this can be built manually, no?
    – kyrlon
    Jun 20, 2023 at 19:27
  • @kyrlon It is always the case, as long as the source is available to you. That's independent of apt
    – Jon
    Jun 20, 2023 at 19:41
  • 2
    This post is at best a comment on the availability of packages (related to the question) and ESM support (unrelated to the question), and not an answer at all.
    – muru
    Jun 21, 2023 at 6:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .