> I'm surprised that people consider Python to be part of it. However, APT depends on Perl

Pardon?

  $ file `which apt`
  /usr/local/bin/apt: Python script, ASCII text executable

Which apt is that?

? file `which apt`

/usr/bin/apt: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=157631f2617f73dee730273c7c598fd4d17b7284, for GNU/Linux 3.2.0, stripped

Debian doesn't ship files in /usr/local.

You can of course add your own "apt" binary in /usr/local/bin/apt which can be written in any language you like, say COBOL, Java, Common Lisp or Python.

Ah, of course. I guess this wrapper is provided by Mint.

I am curious: What does the wrapper do? Can you share the source code here?

It appears to re-organize various apt-related commands and sub-commands (including ones provided by additional distro-specific scripts) so that they're all available as sub-commands of `apt`. I don't do much micro-management so I haven't really thought about what the "proper" underlying commands are, except when I've had to look up specific `dpkg` invocations. It's about 200 lines.

Sorry, I meant that something in the package management stack depends on Perl (not APT specifically).

It looks like in trixie, it's libpam-modules that pulls in debconf, which is written in Perl. And libpam-modules is required by util-linux, which is Essential: yes.

I wonder how much of that Perl support is simply regex and other parsing utilities.

I’ve notice a lot of that in base OS systems

Its a curiosity more than anything though

A substantial fraction of apt is written in perl. It's actually still pretty core to debian, even if applications are using it less.

There is no Perl code in APT itself, nor in dpkg on the installing side; Perl is used by dpkg-dev, i.e. when building packages.

Ah, my apologies. I must admit I am not entirely clear on where the boundaries are between the different tools and other elements of the debian packaging process.