Re: [Dovecot] dovecot tring to load sql modules
On Sun, Aug 13, 2006 at 10:15:43AM -0700, Dean Gibson (Mail Administrator) wrote:
On 2006-08-13 02:50, Axel Thimm wrote:
The fix is to _never_ use --nodeps in rpm and other package managers, and to simply add the mysql libs and ignore their presence.
Unless you are setting up an embedded system and are running out of space there is no reason not to allow mysql libs to install.
OT gripe:
Well, if that's what I have to do, that's what I'll do. It's getting to the state where, when you install Linux, you just have to install everything, or administration becomes a treasure hunt. Otherwise, every time you want to install a package, you have to go on a treasure hunt. It's also why I search for RPMS rather than doing a build from source; that's also a treasure hunt for more files. Do you know that you can't run the printer command-line configuration tools on Linux unless you have the GUI installed? You can't set the time zone with the tools provided unless you have some other giant package installed (I forget which) that I don't need. I run several Linux servers, and I don't need that GUI crap on each server. I thought one of the fundamental security concepts was, if you don't need it, don't install it.
Installing support for mysql client libs does not imply you have to run a mysql server (or even access one). That's what security is about when discussing minimal systems in a security context.
I first started with RH Linux 5.2 and it was a joy. However, starting with about RH Linux 7.0, Linux developers have lost sight of the original goal, in my opinion, which is to have a small, easily managed server system.
I don't have any problem with the dovecot RPM having support for God knows what, built in. What would be nice is that if I don't reference it in dovecot.conf, then it doesn't get called.
Do you need hyperbole and elliptic functions? Or maybe not even sqrt? Should then glibc allow riping them out? Of course not.
And what shoudl any packaging system do when you suddenly do reference mysql support in dovecot.conf? Should it automatically install the missing libs the moment you leave the editor?
End of gripe. I'll go find the required (but unused) packages and install them, and hope that they don't drag in stall more (unused) crap.
If you use --nodeps you'll end up with a broken system.
Axel.Thimm at ATrpms.net
On 2006-08-13 11:11, Axel Thimm wrote:
Installing support for mysql client libs does not imply you have to run a mysql server (or even access one). That's what security is about when discussing minimal systems in a security context.
Really? And how do you install JUST the client libs? On my Fedora Core 1 CD-ROMS, there are:
/Fedora/RPMS/mysql-3.23.58-4.i386.rpm /Fedora/RPMS/mysql-bench-3.23.58-4.i386.rpm /Fedora/RPMS/mysql-devel-3.23.58-4.i386.rpm /Fedora/RPMS/mysql-server-3.23.58-4.i386.rpm
The only way to get libmysqlclient.so.10 is to install the base mysql-3.23.58-4.i386.rpm. However, that requires:
perl(DBI) is needed by mysql-3.23.58-4
perl-DBD-MySQL is needed by mysql-3.23.58-4
perl-DBI is needed by mysql-3.23.58-4
And who knows WHAT from there. I already have PERL installed, but not the above packages.
Oh, and by the way, the dovecot RPM I downloaded also "needs" SQLite;
that isn't even on my FC1 CD-ROMS. Who knows what kind of treasure hunt
THAT requires.
Do you need hyperbole and elliptic functions? Or maybe not even sqrt?
Should then glibc allow riping them out? Of course not.
That's silly. Those are standard C-library routines, not major packages.
And what should any packaging system do when you suddenly do reference mysql support in dovecot.conf? Should it automatically install the missing libs the moment you leave the editor?
The packaging system shouldn't do anything. If I were ever to suddenly reference mysql support in dovecot.conf, I expect to THEN get the error message I got, and then it is then MY responsibility to go install all the MySQL crap I need. Of course, I'd use PostgreSQL instead of MySQL, but that's another story.
Fortunately, when I gave up chasing the MySQL RPM dependency trail and downloaded the dovecot source, for some inexplicable reason it built without having to engage in the usual "include file treasure hunt". It took a couple builds (getting pam-dev and OpenSSL-dev, and for some reason e2fsprogs-dev), and a couple configuration fits and starts, but now Dovecot is up and running.
So why did I move from UW-IMAP to Dovecot? Because UW-IMAP requires all the clients to specify the mail subdirectory. That works fine for most mail clients, but it doesn't work with the default mail client on Pocket PCs. While that is a deficiency in the Pocket PC mail client, it is also a deficiency in UW-IMAP, where the author refuses to make it a configuration option, claiming that he intended the daemon to be "plug-and-play". This laughable attitude is so typical of many Unix developers, that it's somehow more important for the SERVER to be "plug-and-play" than it is for the CLIENT to be "plug-and-play". No wonder Linux is not replacing Windows among most users. No wonder that RedHat dropped UW-IMAP from its distributions.
-- Dean
On Sun, Aug 13, 2006 at 02:20:41PM -0700, Dean Gibson (Mail Administrator) wrote:
On 2006-08-13 11:11, Axel Thimm wrote:
Installing support for mysql client libs does not imply you have to run a mysql server (or even access one). That's what security is about when discussing minimal systems in a security context.
Really? And how do you install JUST the client libs? [... more rant on how to install things ...]
On every modern distribution, or better said, on every distribution but LFS you have depsolver tools that automatically cater for the dependencies, no one is on "treasure hunts" since ages. For Fedora Core take your pick:
smart install dovecot
yum install dovecot
apt-get install dovecot
On FC1 it yields the following:
# smart install dovecot Loading cache... Updating cache... ######################################## [100%]
Computing transaction...
Installing packages (21):
SysVinit-2.85-5@i386 mysql-3.23.58-4@i386
cyrus-sasl-2.1.15-6@i386 net-tools-1.60-20.1@i386
cyrus-sasl-md5-2.1.15-6@i386 openldap-2.1.22-8@i386
dovecot-1.0-0_19.rc6.fc1.at@i386 perl-DBD-MySQL-2.9002-1@i386
ethtool-1.8-2.1@i386 perl-DBI-1.37-1@i386
fedora-release-1-3@i386 postgresql-libs-7.3.4-2@i386
initscripts-7.42-1@i386 procps-2.0.17-1@i386
iproute-2.4.7-11@i386 psmisc-21.3-2.RHEL.0@i386
iputils-20020927-9.1@i386 sysklogd-1.4.1-13@i386
mingetty-1.06-2@i386 util-linux-2.11y-29@i386
mount-2.11y-29@i386
12.9MB of package files are needed. 32.7MB will be used.
Confirm changes? (Y/n):
That's all there is to "treasure hunts".
And what should any packaging system do when you suddenly do reference mysql support in dovecot.conf? Should it automatically install the missing libs the moment you leave the editor?
The packaging system shouldn't do anything. If I were ever to suddenly reference mysql support in dovecot.conf, I expect to THEN get the error message I got,
You got an error message because you explicitly broke package and library dependencies, you want such a breakage to be the default mode of packaging and library management? Sorry, that's totally unacceptable.
Fortunately, when I gave up chasing the MySQL RPM dependency trail and downloaded the dovecot source, for some inexplicable reason it built without having to engage in the usual "include file treasure hunt". It took a couple builds (getting pam-dev and OpenSSL-dev, and for some reason e2fsprogs-dev), and a couple configuration fits and starts, but now Dovecot is up and running.
I'm a Fedora/Red Hat user and in a parallel thread a gentoo user and myself were making distributions jokes. But to be honest I like gentoo, if I were to use source based distribution, I would go gentoo.
From what you write *you are a gentoo user*, but possibly don't know that yet. If you need taylored, minimal setups tuned to your liking and matching your demands and your hardware you need to use gentoo (or other similar distributions).
Axel.Thimm at ATrpms.net
participants (3)
-
Axel Thimm
-
Dean Gibson (Mail Administrator)
-
Jan Kundrát