Confusing state of Percona Software Repositories (apt)

MySQL & MariaDB Percona Server for MySQL 8.0
,
1

Honestly, I find the current state of Percona Software repositories for apt tremendously confusing (not sure if the state of rpm repositories is the same):

  • The documentation ( MySQL software repositories - Percona Software Repositories ) lists “MySQL software repositories” and repositories for “Percona Distribution for MySQL” - tbh I don’t understand which of the two “classes” of repos is recommended if I want to install the percona’s mysql on a production server. What is actually the difference?
  • When trying to choose pdps-8.0 on trixie, it tells me this operating is not supported, but on bookworm it works fine
  • ps-80 on the other hand works on both trixie and bookworm, but as a side effect enables the tools repository, that’s supposed to be deprecated (see htttps://www.percona.com/blog/important-update-streamlined-repository-management-for-improved-efficiency/)
  • Enabling a deprecated repo wouldn’t be so bad if it was actually dormant, but on Jan 13 (10 days ago) a broken version of libdbd-mysql-perl with a higher version number than any other (working) libdbd-mysql-perl version, leading to broken perl tools on all servers utilizing the ps-80 repository (actually not for trixie as packages for trixie are not available in that repo)

For Debian users this means that they have to manually disable the tools repo and/or apt mark libdbd-mysql-perl to a non-broken version and/or use pdps-80 instead of ps-80 if available for their current platform. This results in heavy cognitive workload when managing a large fleet of servers with different Debian and MySQL versions.

It would be really great, if somebody at Percona could do any/either of the following:

  • revert toolsback to a non-broken libdbd-mysql-perl version
  • prevent ps-80 from force-enabling tools
  • add a short note to the documentation explaining what the difference between ps-80 and pdps-8.0 (or ps-84-lts and pdps-84-lts - same confusion) is and which variant is recommended under which circumstances.
2

(For completeness / search benefits: the broken libdb-mysql-perl(version 5.013) results in Can’t load mysql.so and undefined symbol: mysql_sqlstate error messages and seems to be the cause for at least these forum issues:

and possible more, that I didn’t find)

3

and also this Jira issue: Jira

4

I can’t clarify on the repo stuff, but the differences between PS and PDPS are noted in the documentation

Basically, PS is “just mysql”, and PDPS is “mysql + lots of other tools”

1 Like
5

Hi @rwunderer

Please check if the latest version (1.0-32) of percona-release is used.

Screenshot 2026-01-24 at 20.34.23
Screenshot 2026-01-24 at 20.34.23868×662 33.8 KB

6

Hi @Vadim_Yalovets ,

thanks for your reply.

I checked, and yes, it is version 1.0-32 of percona-release on all systems.

However I discovered that

  • ˋpercona-release enable ps-80ˋ indeed works as expected
  • but ˋpercona-release setup ps-80ˋ still tries to enable the ˋtoolsˋ repository

Is this a bug or is ˋpercona-release setupˋ deprecated and shouldn’t be used anymore?

7

Thanks @matthewb !

Given how often that particular question pops up, maybe Percona should think about deprecating individual repos alltogether and keep only the “distribution” repos?

Personally as a systems administrator I wouldn’t mind at all having to enable PDPS on a server where I needed only a single tool (eg xtrabackup). After all I have all of Debian enabled too, while using only a small subset of the available packages.

Actually I would even prefer not having to fiddle with ˋpercona-releaseˋ at all. Having a “repo management” tool on top of the regular package management tools makes automating things (eg in Ansible) a bit cumbersome. Having just a simple repo file to drop in would make things a lot easier.

Personally (and from reading other forum posts I have the feeling many others share this view as well) I see these options in order of declining preference:

  1. a single ˋperconaˋ repo where I pick any package using apt/rpm or appropriate automation tooling
  2. one repo per Percona “product line” (eg MySQL, PostgreSQL, Mongo, etc.) where again I pick what I need with the usual tools
  3. one repo per tool (xtrabackup, pt-toolkit, mysql, etc)
  4. the current situation (as a combination of 2 and 3)

In 1. and 2. ˋpercona-releaseˋ wouldn’t be needed as repo management would be straight forward.

I appreciate what Percona is doing for the community and I’m not complaining. I just thought I’d throw in my perspective in case Percona wants to reorganise the repo structure one day. :slightly_smiling_face: