# Confusing state of Percona Software Repositories (apt) **URL:** \ **Category:** Percona Server for MySQL 8.0\ **Tags:** mysql, percona\ **Created:** [January 23, 2026, 11:09am UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092 "2026-01-23T11:09:20Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![rwunderer](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rwunderer/32/8934_2.png) [@rwunderer](https://forums.percona.com/u/rwunderer)\ **Post date:** [January 23, 2026, 11:09am UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/1 "2026-01-23T11:09:20Z")
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](https://docs.percona.com/percona-software-repositories/mysql.html) ) 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 `tools`back 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. ---
**Author:** ![rwunderer](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rwunderer/32/8934_2.png) [@rwunderer](https://forums.percona.com/u/rwunderer)\ **Post date:** [January 23, 2026, 11:09am UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/2 "2026-01-23T11:09:50Z")
(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: - [Percona toolkit pt-show-grants 3.7.1 broken on Debian 13 - #5 by thomariobros](https://forums.percona.com/t/percona-toolkit-pt-show-grants-3-7-1-broken-on-debian-13/40009/5) - [Libdbd-mysql-perl 1:5.013-1.noble breaks DBD::mysql after apt upgrade on Ubuntu 24.04](https://forums.percona.com/t/libdbd-mysql-perl-1-5-013-1-noble-breaks-dbd-mysql-after-apt-upgrade-on-ubuntu-24-04/40080) and possible more, that I didn’t find) ---
**Author:** ![rwunderer](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rwunderer/32/8934_2.png) [@rwunderer](https://forums.percona.com/u/rwunderer)\ **Post date:** [January 23, 2026, 11:10am UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/3 "2026-01-23T11:10:31Z")
and also this Jira issue: [Jira](https://perconadev.atlassian.net/browse/PT-2509) ---
**Author:** ![matthewb](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/matthewb/32/34_2.png) [@matthewb](https://forums.percona.com/u/matthewb)\ **Post date:** [January 23, 2026, 7:48pm UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/4 "2026-01-23T19:48:14Z")
I can’t clarify on the repo stuff, but the differences between PS and PDPS are noted in the documentation > **[Percona Distribution for MySQL - Components](https://docs.percona.com/percona-distribution-for-mysql/8.4/components.html)** > > Percona Distribution for MySQL consists of the following components: Basically, PS is “just mysql”, and PDPS is “mysql + lots of other tools” ---
**Author:** ![Vadim\_Yalovets](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/vadim_yalovets/32/43_2.png) [@Vadim\_Yalovets](https://forums.percona.com/u/Vadim_Yalovets)\ **Post date:** [January 24, 2026, 6:35pm UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/5 "2026-01-24T18:35:55Z")
Hi @rwunderer > [@rwunderer](#): > > prevent `ps-80` from force-enabling `tools` Please check if the latest version (1.0-32) of percona-release is used. ![Screenshot 2026-01-24 at 20.34.23](https://us1.discourse-cdn.com/flex019/uploads/percona1/original/3X/7/d/7db3901482dc3565ce30d98ba072360cb6bf45aa.png) ---
**Author:** ![rwunderer](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rwunderer/32/8934_2.png) [@rwunderer](https://forums.percona.com/u/rwunderer)\ **Post date:** [January 25, 2026, 7:10am UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/6 "2026-01-25T07:10:01Z")
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? ---
**Author:** ![rwunderer](https://sea1.discourse-cdn.com/flex019/user_avatar/forums.percona.com/rwunderer/32/8934_2.png) [@rwunderer](https://forums.percona.com/u/rwunderer)\ **Post date:** [January 25, 2026, 8:01am UTC](https://forums.percona.com/t/confusing-state-of-percona-software-repositories-apt/40092/7 "2026-01-25T08:01:24Z")
> [@matthewb](#): > > Basically, PS is “just mysql”, and PDPS is “mysql + lots of other tools” 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. 🙂