... I am using postfix with MySQL support for email, so I do not want to remove this 'dependency'... my conundrum is how to remove postgresql without removing postfix (tried -x postifx; did not work).

Any Suggestions Welcome
Ian

andrewthomas

08-23-2011 08:36 PM

Since postgresql-8.1.23 is a dependency of postfix-2.3.3, no you can't.

You either have to live with postgresql or you have to rebuild postfix so it does not require postgresql.

scottro11

08-23-2011 08:40 PM

You can try doing rpm -e --nodeps postgresql

The question is will postfix mysql-pgsql still run.

Looking on CentOS 6, don't see that package.

Note that using --nodeps can be dangerous and break things. However, you can remove it, then see if postfix works without problems. If it does, then fine, if not, reinstall it.

A handy command is

rpm -q --whatrequires

For example, I see I also have postgresql-libs installed. Not sure what pulled it in.

However, if I run

rpm -q --whatrequires postgresql-libs I get an answer that nothing requires it.

Yet, if I run yum remove postgresql-libs, it wants to remove openoffice and several other packages.

RH is a rather bloated distribution, and tends to throw in the kitchen sink--I remember once, trying to remove wireless-tools and yum wanted to remove a bunch of things that have no connection with it, IIRC, probably everything network connected. While --nodeps can, as I said, be quite dangerous at times, other times it's quite safe to do so.

Thanks for giving us the followup. In that case, don't do the --nodeps, as we see, apparently, anyway, it would have broken things.

One interesting thing that I found after posting was that although whatrequires said nothing needed postgresql-libs (on CentOS 6), when I went to remove it, not by yum, but by rpm -e, I would then get an error message of failed dependencies, that a particular library it supplied was needed by another, completely unrelated program.

This is another thing that RH seems to do more often than others, and another reason why using --nodeps can be dangerous. Program A needs shared object B, which is provided by completely unrelated program C. So, A will pull in C, just because C is the only thing that provides shared object B. I don't know how much of this is due to bad or sloppy packaging and how much is really the best way, but it's another reason one winds up with so many odd dependencies, that have nothing to do with the kitchen sink attitude.