Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I had mysql-server-5.1 installed, then upgraded to mysql-server-5.5 and now upgraded to percona server (package percona-server-server-5.5). So now I have 2 mysql-server packages removed, but not purged (in "rc" state). I tried to purge mysql-server-5.1 and during this, it stopped the percona server!

dpkg -L mysql-server-5.1
/etc
/etc/mysql
/etc/mysql/conf.d
/etc/init.d
/etc/logrotate.d
/etc/logcheck
/etc/logcheck/ignore.d.server
/etc/logcheck/ignore.d.server/mysql-server-5_1
/etc/logcheck/ignore.d.paranoid
/etc/logcheck/ignore.d.paranoid/mysql-server-5_1
/etc/logcheck/ignore.d.workstation
/etc/logcheck/ignore.d.workstation/mysql-server-5_1

How can I get rid from mysql-server-* packages without affecting the running system?

share|improve this question

1 Answer 1

up vote 2 down vote accepted

Obviously, Percona and MySQL are closely related (certainly going by the former's web page), so APT thinks it should stop it. This could well be a slight bug in one of the package scripts.

You could try one of two things:

  1. Report this as a bug, upgrade the problem package(s), then purge MySQL.
  2. Hack it. My favourite method: add exit 0 right after line 1 on the /etc/init.d script causing the issue. Don't forget to undo the change after you're done! I wouldn't recommend this in the general case, but if you're sure about the nature of the dependency and you know that purging MySQL won't break anything in Percona, it could work.

The second option is an acceptable method of solving this class of bizarre dependency issues, e.g. when you're upgrading a live machine that hasn't seen an upgrade for ages nad has old and/or buggy packages as a result. But I'd be extra careful. And have a failover server ready, if you have one.

share|improve this answer
    
I can do that when I am sure what is the cause... In the past I have seen "purge" job removing config files which were part also of another package - and it is hard to predict how will the purge process work... maybe workaround would be to remove the files by myself and alter package information (where??) so that it contains no files... but still it could run stop script... so also alter postrm script? Or which one is executed during purge? –  Marki555 May 22 '12 at 11:10
    
I'd be careful about that. If this is a critical server and there's no failover, your absolutely best bet is to schedule maintenance on the machine, and just purge the package. Scheduled downtime is more acceptable, and you have the advantage of not trying to second-guess package dependencies. –  Alexios May 22 '12 at 11:35
    
Finally I added that exit 0 at the beginning of /var/lib/dpkg/info/mysql-server-5.5.postrm (after checking that it doesn't do anything useful when another mysql server package is still installed) and removing few files from /var/lib/dpkg/info/mysql-server-5.5.list. –  Marki555 May 23 '12 at 6:17

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.