• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Question Catastrophic apt-get install removes Plesk??

I think I need to eat crow.

I re-attached my backup to another Linode, and sure enough, I got a Y/N prompt. So that's hard to argue! Probably didn't have the best memory of the specifics due to the stress of the moment.

However, there are lots of routine "Y/N" prompts from known familiar packages, but yes, a lot more staring at the dependency warning is in order. Mytop obviously removes some scary packages if you proceed without caution.

So, I think I can reduce my Plesk anxiety quite a bit here. But yeah, mytop is a weird one for sure: I've been spoiled by safe package installs, clearly.
 
I still think it is strange that an install of something could cause an uninstall of something else. I know the other way round can happen. You install a component and this component needs other components to be installed or updated.
If there's a conflict, the course of action is to remove the conflicts. That's what the package manager attempts to do.

I wonder if this is true (under normal circumstances). If the package to be installed conflicts with another package ... why whould it use that conflicting package in the first place? Why wouldn't it just ignore that package? Does not make very much sense I would say. It could conflict with the version of the specific package because it is too old. But then the resolution would be to update that package. Not to remove it.

I took a look at why it was attempting to remove MariaDB exactly. It appears MariaDB bundles mytop:

# dpkg -S mytop
mariadb-client-10.1: /usr/bin/mytop
So when you install mytop from another repository, there's a conflict that requires the removal of MariaDB. Honestly, pretty much have never touched mytop so I had no idea. But there's that at least.
 
I think I need to eat crow.

So glad with Google Translate :)

If there's a conflict, the course of action is to remove the conflicts. That's what the package manager attempts to do.

I get that ... but what I mean is ... if I build package A and it conflicts with package X, then why would I let package A interfere with package X? If I know it would conflict, I would ignore the package (instead of removing it), or update the package to a version that is compatible.

Well let's hope that it's just a weird issue of 'mytop' which maybe is not so 'top' after all.
 
So glad with Google Translate :)



I get that ... but what I mean is ... if I build package A and it conflicts with package X, then why would I let package A interfere with package X? If I know it would conflict, I would ignore the package (instead of removing it), or update the package to a version that is compatible.

Well let's hope that it's just a weird issue of 'mytop' which maybe is not so 'top' after all.
How would you "ignore" the package?
 
Not quite sure what you mean.

Take this example on a more basic level - MariaDB bundles mytop located at /usr/bin/mytop. You want to install another mytop package that also places its binary located at /usr/bin/mytop. What do you do?

1. Remove the current package
2. Return an error on installation
 
3. Update the current package?

I don't know what mytop is or does ... but it feels strange that 1 install can remove so many other components.
 
But mariadb wants mytop v1 (example). Apt wants to install mytop v2. mytop isn't a "dependency" of MDB here - its literally part of the package. Apt can't reasonably just "upgrade" the package - for one, I'm guessing it's not a completely version and instead slimmed down. I'd also guess MDB has made modifications (that are present on v1) to make mytop work (better?). Apt doesn't know these specifics (whether or not simply running an in-place "upgrade" would work - so it prompts to remove.
 
You could be right. I truly don't know. It sounds to me as if the mytop package isn't configured correctly then.

I'd also guess MDB has made modifications (that are present on v1) to make mytop work (better?)

Are mytop and MaridDB from the same company? If not, I assume no modifications were made to MariaDB.
 
I truly don't know. I work with a RHEL-based server and can't remember (or imagine) this ever happening.

If the 2 packages are depending on one another, then I would assume installing or updating a component would result in updating the other component.

But ... I'm going offline now ... thanks for the interesting discussion ;)
 
I truly don't know. I work with a RHEL-based server and can't remember (or imagine) this ever happening.
As do I. We keep plesk-core/mariadb protected as a safeguard. I'm not aware of a Ubuntu/Debian equivalent though.

I truly don't know. I work with a RHEL-based server and can't remember (or imagine) this ever happening.
Not really. eg:

MariaDB bundles mytop, with a binary under /usr/bin/mytop. /usr/bin/mytop contains a special change to make it work with MariaDB.

User comes, runs yum/apt install mytop. MyTop detects that "mytop" already exists via MariaDB, conflicting and attempts to remove the packages to prevent conflict.

Why can't it just upgrade in place? Because there's no guarantee MariaDB would continue to work with the new mytop packages. Say you replace /usr/bin/mytop provided by MariaDB with a newer version installed directly via apt. That newer version wouldn't contain the supposed special change necessary for it to work with MariaDB, so now it's broken. It's not an huge issue, because MDB server will probably run without it. But imagine if it was a essential package?

APT/DNF has no way of knowing whether the package can be upgraded, unless it's actually listed by MDB as a dependency/requirement with versioning requirements (I'm sure they have their reasons for doing not doing it this way). It also has no way of knowing to what degree doing an "in-place" upgrade would break MDB. APT doesn't care that it removes something you want. It does try to keep the system consistent, and that involves not trying to monkey patch/pluck various packages together.
 
hello everyone,

here is the listing from my Ubuntu 20 with Plesk 18.0.36 (btw, it will be released soon):
Code:
:~# apt-get install mytop psa pp18.0.36-bootstrapper
Reading package lists... Done
Building dependency tree
Reading state information... Done
pp18.0.36-bootstrapper is already the newest version (18.0-v.ubuntu.20.04+p18.0.36.0+t210526.1459).
psa is already the newest version (18.0.36-v.ubuntu.20.04+p18.0.36.0+t210526.1459).
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 mariadb-client-10.3 : Conflicts: mytop but 1.9.1-4 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.


:~# apt-cache show mytop|grep -A3 'Desc'
Description-en: top like query monitor for MySQL
 Mytop is a console-based tool for monitoring queries and the performance
 of MySQL. It supports version 3.22.x, 3.23.x, 4.x and 5.x servers.
 It's written in Perl and support connections using TCP/IP and UNIX sockets.

not sure is this a bug or not, but seems mytop does not support MariaDB >= 10.x

and this is the reason:
Code:
:~# dpkg -s mariadb-client-10.3 |grep mytop
Replaces: mariadb-client-10.0, mariadb-client-10.1, mariadb-client-10.2, mariadb-client-5.5, mariadb-server-10.0 (<< 10.0.13-1~), mysql-client-5.5, mysql-client-5.6, mysql-client-5.7, mysql-client-8.0, mytop, virtual-mysql-client
Conflicts: mysql-client-core-5.5, mysql-client-core-5.6, mysql-client-core-5.7, mysql-client-core-8.0, mytop, virtual-mysql-client

mytop is a part of MariaDB server 10.3

@Pleskie ,
apt asked you to remove plesk components and you answered 'Yes'. I understand that it happened by mistake or due to rush,
but there's no bug from Plesk side. This is the way how dependencies work..
 
Last edited:
Found something interesting.

Seems like the package mantainer was aware that installing mytop causes removal of the mariadb server since 2019.

Also, check this out: Upgrade from 16.04 to 18.04 wants to remove MariaDB Server
 
part of initial message (below) looks like you did:
Code:
The following packages will be REMOVED:
libpam-plesk mariadb-client-10.3 mariadb-server mariadb-server-10.3 plesk-backup-utilities plesk-completion plesk-config-troubleshooter plesk-core
plesk-core-utilities plesk-dovecot plesk-dovecot-imap-driver plesk-dovecot-pigeonhole plesk-git-http plesk-l10n plesk-mail-pc-driver
plesk-modsecurity-configurator plesk-mysql-server plesk-repair-kit plesk-resctrl plesk-roundcube plesk-service-node-utilities plesk-task-manager plesk-web-hosting
plesk-web-socket pp18.0.35-bootstrapper psa psa-firewall psa-libxml-proxy psa-locale-base-en-us psa-logrotate psa-mail-driver-common psa-phpmyadmin psa-proftpd
psa-updates psa-vhost
The following NEW packages will be installed:
mytop
0 upgraded, 1 newly installed, 35 to remove and 2 not upgraded.
Need to get 31.1 kB of archives.
After this operation, 418 MB disk space will be freed.
Do you want to continue? [Y/n] y
Get:1 Index of /ubuntu focal/universe amd64 mytop all 1.9.1-4 [31.1 kB]


probably you need to check /etc/apt/apt.conf.d/ directory files so they do not contain options below:
Code:
APT::Get::Assume-Yes "true";
APT::Get::force-yes "true";

settings above force apt to answer yes for all questions
 
Back
Top