Why does the latest version of dovecot have mysql as a dependency?
On Sat, 2005-01-15 at 00:21 -0500, Scot L. Harris wrote:
Why does the latest version of dovecot have mysql as a dependency?
-- Scot L. Harris webid@cfl.rr.com
Today is a good day to bribe a high-ranking public official.
Its a conspiracy to generate licensing revenue for AB.
Ted
On Sat, 15 Jan 2005 00:21:28 -0500, Scot L. Harris webid@cfl.rr.com wrote:
Why does the latest version of dovecot have mysql as a dependency?
--
probably because it can use mysql as a backend but more granularity is probably desired. file a bug at bugzilla.redhat.com
On Sat, 2005-01-15 at 07:10, Rahul Sundaram wrote:
On Sat, 15 Jan 2005 00:21:28 -0500, Scot L. Harris webid@cfl.rr.com wrote:
Why does the latest version of dovecot have mysql as a dependency?
--
probably because it can use mysql as a backend but more granularity is probably desired. file a bug at bugzilla.redhat.com
So it uses mysql to handle the account information?
I agree, if this is an option and you can choose to use mysql or not then it should be setup as an add on package.
Will do. Bug 145219 has been added to the database
On Sat, 2005-01-15 at 11:35, Rahul Sundaram wrote:
Hi
So it uses mysql to handle the account information?
afaik it can but it not required
What I figured. Looking a little closer it also appears to have a dependency on postgresql. Did not notice that at first since I already had postgresql installed. :)
The same needs to be done with postgresql as well, both should be optional packages to be installed only if you are using that option with dovecot.
On Sat, 15 Jan 2005 22:14:14 +0530, Rahul Sundaram rahulsundaram@gmail.com wrote:
Hi
The same needs to be done with postgresql as well, both should be optional packages to be installed only if you are using that option with dovecot.
one more thing. You have added your comments against fc2 which will be moved to fedora legacy when fc4 test releases are being made. if this is true of fc3 or even better rhel 4 beta then filing the bug report against those products is likely to recieve a higher priority. just guessing thou
On Sat, 2005-01-15 at 11:44, Rahul Sundaram wrote:
Hi
The same needs to be done with postgresql as well, both should be optional packages to be installed only if you are using that option with dovecot.
agreed. please add your comments to the bug you have already reported
Done. I also included the same comment regarding openssl.
On Sat, 2005-01-15 at 11:46, Rahul Sundaram wrote:
On Sat, 15 Jan 2005 22:14:14 +0530, Rahul Sundaram rahulsundaram@gmail.com wrote:
Hi
The same needs to be done with postgresql as well, both should be optional packages to be installed only if you are using that option with dovecot.
one more thing. You have added your comments against fc2 which will be moved to fedora legacy when fc4 test releases are being made. if this is true of fc3 or even better rhel 4 beta then filing the bug report against those products is likely to recieve a higher priority. just guessing thou
Good point. I found this on an FC2 system. However it is true of FC3 as well. Change has been made. :)
Am Sa, den 15.01.2005 schrieb Scot L. Harris um 17:59:
Done. I also included the same comment regarding openssl.
Scot L. Harris
openssl is required to support POP3s and IMAPs. That should stay in the dovecot dependency. Building dovecot with MySQL or PostgreSQL support should be optional like realised with the Postfix package, where you simply have to rpmbuild --rebuild the SRPM.
Alexander
On Sun, 2005-01-16 at 11:38, Rahul Sundaram wrote:
Hi
Good point. I found this on an FC2 system. However it is true of FC3 as well. Change has been made. :)
warron togami - redhat devel has just confirmed he is planning to do this for fc4
Excellent! There has been some interesting discussion in bugzilla about this issue. I am glad they will modify this for FC4. Having to include mysql and postgresql just to use dovecot is major bloat for most users and IMHO a security risk. It will make security audits more difficult since unused packages are included and adds just that much more code that could have an exploit in it.
-- Regards, Rahul Sundaram
Scot L. Harris wrote:
Excellent! There has been some interesting discussion in bugzilla about this issue. I am glad they will modify this for FC4. Having to include mysql and postgresql just to use dovecot is major bloat for most users and IMHO a security risk. It will make security audits more difficult since unused packages are included and adds just that much more code that could have an exploit in it.
You are overstating the security risk of a single library package that is unused.
Warren
On Sun, 2005-01-16 at 22:24, Warren Togami wrote:
Scot L. Harris wrote:
Excellent! There has been some interesting discussion in bugzilla about this issue. I am glad they will modify this for FC4. Having to include mysql and postgresql just to use dovecot is major bloat for most users and IMHO a security risk. It will make security audits more difficult since unused packages are included and adds just that much more code that could have an exploit in it.
You are overstating the security risk of a single library package that is unused.
Single library? It looked to me as if the whole set of files that make up mysql and postgresql were being pulled in and loaded on the system.
On Sun, Jan 16, 2005 at 05:24:10PM -1000, Warren Togami wrote:
and IMHO a security risk. It will make security audits more difficult since unused packages are included and adds just that much more code that could have an exploit in it.
You are overstating the security risk of a single library package that is unused.
Still, this isn't a good direction to go. There *could* be security problems in any code, and not having what you don't need is the 100% sure way to avoid them. This needs to be split up more. And, it'd be nice to avoid updates which suddenly pull in new dependencies unless it's strictly necessary.
Hi
You are overstating the security risk of a single library package that is unused.
Single library? It looked to me as if the whole set of files that make up mysql and postgresql were being pulled in and loaded on the system.
bloat is a more valid point that security risks IMHO.
disabled services dont present much of a security risk.
On Mon, 17 Jan 2005, Rahul Sundaram wrote:
You are overstating the security risk of a single library package that is unused.
Single library? It looked to me as if the whole set of files that make up mysql and postgresql were being pulled in and loaded on the system.
bloat is a more valid point that security risks IMHO.
disabled services dont present much of a security risk.
200k for the postgresql library, 100k for the mysql library, kerberos support alone is more 'bloated' than 300k.
If you mean the mysql client library is part of a 5MB package and requires a dozen perl packages, maybe. It may be unfortunate that you need it even when you don't use it.
But then again, look at the rest of your system and what stuff you have installed that you may never use. /usr/share/doc, locale, the terminal emulation stuff, maybe some -devel packages you didn't know were there.
5MB is peanuts and a small price to pay for the flexibility of having both mysql and postgresql support and not having to manage every permutation of functionality. You know what distribution you end up having if you go there... :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Mon, 2005-01-17 at 04:08, Rahul Sundaram wrote:
Hi
You are overstating the security risk of a single library package that is unused.
Single library? It looked to me as if the whole set of files that make up mysql and postgresql were being pulled in and loaded on the system.
bloat is a more valid point that security risks IMHO.
disabled services dont present much of a security risk.
Bloat is good enough reason to split these dependencies out. No argument there.
But don't ignore the security implications. Having unneeded code on the system even with the service disabled may provide someone with access to the system (either a known user or a hacker that gets user level privileges through another exploit) the boot strap needed to get root privileges.
Difficult? Yes. But by using best practices and keeping as much unused unneeded code off a server as possible you eliminate such possibilities 100%.
Warren Togami wrote:
You are overstating the security risk of a single library package that is unused.
It isn't a single package, and it isn't limited just to the libraries (it includes some daemons too).
Lately this is becoming a trend. howl and howl-libs are must-have for GNOME (and bunch of other packages), and soon will become must-have for KDE. NetworkManager now requires bind and caching-nameserver. And those are just the few discussed on this mailing list in last couple of days.
So yeah, we do have a security issue here. User's systems are getting bloated with libraries *and* services that it starts to look as out-of-box Windows installation. And we all know how secure that is.
On Mon, Jan 17, 2005 at 10:41:49AM -0600, Aleksandar Milivojevic wrote:
So yeah, we do have a security issue here. User's systems are getting bloated with libraries *and* services that it starts to look as out-of-box Windows installation. And we all know how secure that is.
Or a Red Hat Linux 6.0 installation. :)
On Sat, 2005-01-15 at 11:02, Scot L. Harris wrote:
one more thing. You have added your comments against fc2 which will be moved to fedora legacy when fc4 test releases are being made. if this is true of fc3 or even better rhel 4 beta then filing the bug report against those products is likely to recieve a higher priority. just guessing thou
Good point. I found this on an FC2 system. However it is true of FC3 as well. Change has been made. :)
What is supposed to happen on an FC2 system that has (and needs) mysql 4.x installed, and the current dovecot update now depends on mysql 3.23.x?
On Mon, 2005-01-17 at 14:13, Les Mikesell wrote:
On Sat, 2005-01-15 at 11:02, Scot L. Harris wrote:
one more thing. You have added your comments against fc2 which will be moved to fedora legacy when fc4 test releases are being made. if this is true of fc3 or even better rhel 4 beta then filing the bug report against those products is likely to recieve a higher priority. just guessing thou
Good point. I found this on an FC2 system. However it is true of FC3 as well. Change has been made. :)
What is supposed to happen on an FC2 system that has (and needs) mysql 4.x installed, and the current dovecot update now depends on mysql 3.23.x?
Very good question! Another problem with feature creep. If mysql 4.x was installed from source dovecot would not install unless mysql 3.23.x was installed via rpm. But if mysql 4.x was installed via rpm I would expect dovecot to accept mysql 3.23.x and anything above that. If it is written to look for 3.23.x specifically then you would have to strip dovecot off and install dovecot from source.
On Mon, 2005-01-17 at 13:32, Scot L. Harris wrote:
What is supposed to happen on an FC2 system that has (and needs) mysql 4.x installed, and the current dovecot update now depends on mysql 3.23.x?
Very good question! Another problem with feature creep. If mysql 4.x was installed from source dovecot would not install unless mysql 3.23.x was installed via rpm. But if mysql 4.x was installed via rpm I would expect dovecot to accept mysql 3.23.x and anything above that. If it is written to look for 3.23.x specifically then you would have to strip dovecot off and install dovecot from source.
It wasn't a theoretical question:
I will install/upgrade these to satisfy the dependencies: [deps: perl-DBD-MySQL 2.9003-4.i386] [deps: mysql 3.23.58-9.1.i386] Is this ok [y/N]: n
What happens if I answer yes?
On Mon, 2005-01-17 at 14:41, Les Mikesell wrote:
On Mon, 2005-01-17 at 13:32, Scot L. Harris wrote:
What is supposed to happen on an FC2 system that has (and needs) mysql 4.x installed, and the current dovecot update now depends on mysql 3.23.x?
Very good question! Another problem with feature creep. If mysql 4.x was installed from source dovecot would not install unless mysql 3.23.x was installed via rpm. But if mysql 4.x was installed via rpm I would expect dovecot to accept mysql 3.23.x and anything above that. If it is written to look for 3.23.x specifically then you would have to strip dovecot off and install dovecot from source.
It wasn't a theoretical question:
I will install/upgrade these to satisfy the dependencies: [deps: perl-DBD-MySQL 2.9003-4.i386] [deps: mysql 3.23.58-9.1.i386] Is this ok [y/N]: n
What happens if I answer yes?
Well depending on where your mysql 4.x packages are installed you may end up stepping all over it and breaking things.
Did you install mysql from source or rpm?
Based on the discussion in bugzilla it looks like if you hold off for awhile they may fix this issue.
Comment from bugzilla #145241
Additional Comment #16 From John Dennis (jdennis@redhat.com) on 2005-01-17 13:40 ------- The dependency on postgres and mysql was a mistake, it should have been only on the client libraries. Warren correctly points out rpm's automatic dependency generation would have picked up the dependency. An earlier tester had reported a problem with missing a dependency on libpq.so which is why it was added (but should not have been needed).
As for dependency creep with respect to FC2. It was recognized that FC2 did not have dependency on either the postgres or mysql client libraries. I had an internal discussion as to whether an upgrade could or should exert a new dependency on libraries and the opinion was that it was O.K. But from the response here its obvious this undesirable and I will revert the FC2 requirements.
This is my planned course of action:
For FC2 do not build with mysql and postgres support, it was not present in FC2 previously and that will remain consistent.
For FC3, continue to build with mysql and postgres, this is consistent with the FC3 build.
For devel(A.K.A. FC4) build using the loadable module approach and introduce sub-packages that provide those modules. This creates an "lightweight" main package but provides for site configurable extension.
On Mon, 2005-01-17 at 13:48, Scot L. Harris wrote:
I will install/upgrade these to satisfy the dependencies: [deps: perl-DBD-MySQL 2.9003-4.i386] [deps: mysql 3.23.58-9.1.i386] Is this ok [y/N]: n
What happens if I answer yes?
Well depending on where your mysql 4.x packages are installed you may end up stepping all over it and breaking things.
Did you install mysql from source or rpm?
Rpm - I removed everything related to the stock mysql first.
Based on the discussion in bugzilla it looks like if you hold off for awhile they may fix this issue.
Thanks. I could just remove dovecot on this box, but I'd like to see how this plays out. I thought there was some kind of backwards compatibility package for mysql 4.x too, but I'm not sure how it works or whether it satisfies all the rpm dependencies. Maybe it's time to convert to postgresql...
On Mon, 2005-01-17 at 15:32, Les Mikesell wrote:
Based on the discussion in bugzilla it looks like if you hold off for awhile they may fix this issue.
Thanks. I could just remove dovecot on this box, but I'd like to see how this plays out. I thought there was some kind of backwards compatibility package for mysql 4.x too, but I'm not sure how it works or whether it satisfies all the rpm dependencies. Maybe it's time to convert to postgresql...
Not sure about a backwards compatibility package.
Switching to postgresql may be extreme. And in this case would solve the problem only if you were using the one packaged for FC2 which probably would be the case. Personally I like postgresql better than mysql but switching over for this reason alone is to extreme.
Hopefully they will fix the packages to remove the dependency soon in FC2. FC3 will have the dependency but hopefully it will be corrected to just the client library like it was intended. FC4 and beyond they should split out the requirements in alternate packages kind of like PHP does.
Hi
Lately this is becoming a trend. howl and howl-libs are must-have for GNOME (and bunch of other packages), and soon will become must-have for KDE.
what is bloat for you is a must have feature for many others. this is progress. many people consider anything more featureful than fluxbox as bloat. doesnt mean gnome can afford NOT to add features to stay competitive.
NetworkManager now requires bind and caching-nameserver. And
those are just the few discussed on this mailing list in last couple of days.
this one probably can be improved.
On Tue, 2005-01-18 at 05:17, Rahul Sundaram wrote:
Lately this is becoming a trend. howl and howl-libs are must-have for GNOME (and bunch of other packages), and soon will become must-have for KDE.
what is bloat for you is a must have feature for many others. this is progress. many people consider anything more featureful than fluxbox as bloat. doesnt mean gnome can afford NOT to add features to stay competitive.
Isn't that why dynamic linking was invented years ago: so you could wait until you actually needed something to require and load it instead of requiring that you install every possible thing and resolving all those symbols every time you load a program?
Les Mikesell wrote:
What is supposed to happen on an FC2 system that has (and needs) mysql 4.x installed, and the current dovecot update now depends on mysql 3.23.x?
You can install MySQL-shared-compat-4.1.8-0.i386.rpm and dovecot will install just fine. I've done this numerous times. The shared-compat rpm contains libraries for both 3.23.x as well as 4.1.x
Rahul Sundaram wrote:
what is bloat for you is a must have feature for many others. this is progress. many people consider anything more featureful than fluxbox as bloat. doesnt mean gnome can afford NOT to add features to stay competitive.
The only problem I have with this, is that Windows XP is running about four to five times *faster* on my old laptop, than FC3 with GNOME.
From the moment I power up my laptop, it takes about two minutes to get to Windows login prompt. It takes almost 10 to get to GNOME login prompt. I usually go make myself cup of coffe when I plan to boot FC3 on it. When I login, Windows is about two times faster to get me to the desktop than GNOME. Running thunderbird and firefox under Windows is usable. Running them under FC3/GNOME, well let call it usable, but so much slower (good thing I made myself that cup of coffe).
I wouldn't call this a progress. Something to think about next time more bloat is added.
Hi
The only problem I have with this, is that Windows XP is running about four to five times *faster* on my old laptop, than FC3 with GNOME.
not just because of features. there are several other reasons why this could be a problem
1)xfree86 lived in a cave for a long time 2) performance enhancements are of less priority and more involved than adding new features. any help would of course be appreciated
I wouldn't call this a progress. Something to think about next time more bloat is added.
nope. we shouldnt stop adding features to better optimise the system. we should optimise those features to peform better instead.
Rahul Sundaram wrote:
- performance enhancements are of less priority and more involved
than adding new features. any help would of course be appreciated
nope. we shouldnt stop adding features to better optimise the system. we should optimise those features to peform better instead.
Combine those two statements, and you'll end up with a system that nobody will want to use -- simply because it is painfully slow. Hack, I'm booting my laptop into Windows more often than into Linux because of exactly this reason. If the performance was comparable, Windows would be booted only when I needed to use MS Streets&Trips (and probably removed from the disk if I could get Linux equivalent). The way it is now, Windows is booted whenever I want to get something done. Linux only when I have spare time to fool around and nothing better to do in my life. I'm not even booting Linux to show my friends. It would be embarasing how slow the complete system (with GUI) is.
Linux (as complete system, not just the kernel) gained its popularity because it used to be small, fast, and stable. Not because it had tons of bloated features that users could really live without. If I wanted Windows clone, I could just left pre-installed copy of Windows. And it would run much faster.
Alexander Dalloz wrote:
Am Sa, den 15.01.2005 schrieb Scot L. Harris um 17:59:
Done. I also included the same comment regarding openssl.
Scot L. Harris
openssl is required to support POP3s and IMAPs. That should stay in the dovecot dependency.
Actually, OpenSSL is required for quite a few packages. Unfortunately, OpenSSL is not a required package, but an optional package.
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe that its not there on the CDs somewhere.. Alan
Alan McDonald wrote:
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe that its not there on the CDs somewhere.. Alan
[rlc@bobcp4 ~]$ rpm -q --whatprovides /usr/lib64/libmysqlclient.so.14 MySQL-shared-4.1.7-0.glibc23
Just adjust the query shown above for the full path of the file you are interested in. But it's probably on MySQL-shared (or mysql-shared, depending on where you get the package from.)
Bob
On Mon, 7 Feb 2005 00:32:47 +1100, Alan McDonald alan@meta.com.au wrote:
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe that its not there on the CDs somewhere.. Alan
Your subject line says libmysqlclient.so.10 but your text says libmysqlclient.so.0.
Which one do you want?
In either case, if you already have it on your system, and if it was installed with RPM (or Yum) then you can run the following command to tell you which package installed it:
rpm -q --whatprovides /path/to/libmysqlclient.so.10
On my machine, using the original FC3 packages, it would have been provided by the mysql-3.23.58 package (I think it was version 3.23.58, but I'm not sure because I use a newer version.)
On my machine I am using MySQL 4.1.9, so in order to get the "10" version for compatibility with other packages, I installed MySQL-shared-compat-4.1.9-0 which I downloaded from the mysql.org web site along with the other RPM packages for MySQL-client and MySQL-server.
1) locate libmysqlclient ....... /usr/lib/mysql/libmysqlclient.so ........
2) rpm -qf /usr/lib/mysql/libmysqlclient.so mysql-devel-3.23.58-14
Easy no!!! Bye Alex
On Sun, 06 Feb 2005 09:59:02 -0500, Robert L Cochran cochranb@speakeasy.net wrote:
Alan McDonald wrote:
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe that its not there on the CDs somewhere.. Alan
Thanks Afros, but no, this only works if the file exists on my system. I want to install MySQL and I get this dependency error. Now I want to install it from the CDs but I have tried many of the rms of the CD to try to install this lib but to know avail. There are a lot of rpms which depend ont his lib but no sign of it on the CD. I can't beleive that I need to go the website and download the shared rpm to get it. Surely it's on the CD? I have many boxes to build - I can't believe the CDs are only the partial MySQL setup Alan PS, I need the .so.10 lib but another box I have only has the .so.10.0.0 lib. Are they the same? what's involved in moving the one I have over to the other box?
-----Original Message----- From: fedora-list-bounces@redhat.com [mailto:fedora-list-bounces@redhat.com]On Behalf Of Afros IT Dpt. Sent: Monday, February 07, 2005 3:45 AM To: For users of Fedora Core releases Subject: Re: libmysqlclient.so.10
- locate libmysqlclient
....... /usr/lib/mysql/libmysqlclient.so ........
- rpm -qf /usr/lib/mysql/libmysqlclient.so
mysql-devel-3.23.58-14
Easy no!!! Bye Alex
On Sun, 06 Feb 2005 09:59:02 -0500, Robert L Cochran cochranb@speakeasy.net wrote:
Alan McDonald wrote:
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe
that its not
there on the CDs somewhere.. Alan
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
On Mon, 7 Feb 2005 07:37:50 +1100, Alan McDonald alan@meta.com.au wrote:
Thanks Afros, but no, this only works if the file exists on my system. I want to install MySQL and I get this dependency error. Now I want to install it from the CDs but I have tried many of the rms of the CD to try to install this lib but to know avail. There are a lot of rpms which depend ont his lib but no sign of it on the CD. I can't beleive that I need to go the website and download the shared rpm to get it. Surely it's on the CD? I have many boxes to build - I can't believe the CDs are only the partial MySQL setup Alan PS, I need the .so.10 lib but another box I have only has the .so.10.0.0 lib. Are they the same? what's involved in moving the one I have over to the other box?
I'm not sure I would just copy it because you still have to get it registered with the system so it knows what library files you have. Installing it from RPM would do that for you.
Here's the problem though. You say you want to install from CD, but how did you get MySQL-4.1.9? The FC3 CDs don't have 4.1.9 on them. If you try to install 4.1.9 as an upgrade to your 3.23.xx installation, it will attempt to remove the .10 version to upgrade it to the .14 version. But the .10 version is required to satisy other dependencies. If you downloaded 4.1.9 to install, then why not download the shared-compat-4.1.9 file and install that?
The whole reason for the shared-compat file's existence is to allow you to satisfy the dependencies for packages that require the .10 version, while still installing the .14 version as well.
Am Montag, den 07.02.2005, 00:32 +1100 schrieb Alan McDonald:
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe that its not there on the CDs somewhere.. Alan
Alan, what about using yum for your needs?
It resolves all dependencies and does everything you want. I think in respect you are not clued enough to get all the dependencies figured out by yourself. So please use a package manager like yum or apt.
On Mon, 2005-02-07 at 10:10 +0100, Stefan Held wrote:
Am Montag, den 07.02.2005, 00:32 +1100 schrieb Alan McDonald:
Can someone tell me in which rpm on the Fedora disks, is the rpm which contains the libmysqlclient.so.0 library? I'm trying to install the server manually and I can;t believe that its not there on the CDs somewhere.. Alan
Alan, what about using yum for your needs?
It resolves all dependencies and does everything you want. I think in respect you are not clued enough to get all the dependencies figured out by yourself. So please use a package manager like yum or apt.
It should be in mysql. However, on mine (FC3) that library is libmysqlclient.so.10 and I do not see anything with the .0 level. Are you sure you are looking for the correct file?
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
-
Afros IT Dpt. -
Alan McDonald -
Aleksandar Milivojevic -
Alexander Dalloz -
Ashley M. Kirchner -
Dag Wieers -
David Hoffman -
James McKenzie -
Jeff Vian -
Les Mikesell -
Matthew Miller -
Rahul Sundaram -
Robert L Cochran -
Scot L. Harris -
Stefan Held -
Ted Kaczmarek -
Warren Togami