Bug 145241 - dovecot: optional auth should be in loadable modules in separate packages
dovecot: optional auth should be in loadable modules in separate packages
Product: Fedora
Classification: Fedora
Component: dovecot (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Janousek
: 145371 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2005-01-15 15:06 EST by Michal Jaegermann
Modified: 2014-01-21 17:51 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-08-10 08:17:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2005-01-15 15:06:44 EST
Description of problem:

Version dovecot-0.99.13-1.devel basically was dependent on
openssl for external packages; which is reasonable in the context.
dovecot-0.99.13-2.devel list in dependencies also such heavyweights
as mysql and postgresql.  One wonders when Oracle and few other
databases will also show on that list.  This is annoying and
couterproductive.  Pretty soon everything will depend on everything 
and the whole system will stop making any sense.  On a server with
dovecot I may NOT WANT to have any database and even if some then
not likely all of them.

A simple solution is not add bogus dependencies for _optional_
capabilities of packages.  If somebody wants to use that then
surely they will know where to find other components they need.
If that puts too much faith in intelligence of users then extra
stuff should be split in sub-packages which upon installation
will pull in underlying dependents.

Version-Release number of selected component (if applicable):
Comment 1 Warren Togami 2005-01-15 18:39:38 EST
They are not "bogus" dependencies but rather RPM auto-dep picking up
that dovecot is now linked against those libraries.  Linking against
those libraries does NOT require you to install the entire database
software, but only the tiny library package.  yum will do that
automatically for you during update.

However I do agree that it is somewhat annoying to have dependencies
creep like this during a version update.  FC3 shipped linked against
both mysql and postgresql libs, but FC2 didn't have mysql and
postgresql capable dovecot at first.

So we have two options:
1) Disable mysql and postgresql support in FC2's dovecot update. 
Drawback would be people who want to use these abilities would need to
upgrade to FC3 or build their own dovecot.  Both would be large hassles.
2) Keep mysql and postgresql support, necessitating the installation
of client libraries where they are not needed.  This is done
automatically by update tools so only a tiny hassle.

#1 is acceptable as a solution if nobody is using that capability in
FC2 dovecot, which may be the case because FC2 never had that ability
originally.  Otherwise #2 would be preferrable because it does not
necessarily HURT anyone, and it is an easy automated operation.

User votes and opinions on this matter would be appreciated.
Comment 2 Pedro Silva 2005-01-15 18:55:02 EST
I could go with solution #2, although I don't use mysql or postgresql directly
with dovecot, I think taking away features is not good. I understand that
dovecot's features in FC2 didn't include mysql/pgsql support but installing
client libraries is not a big hassle.
Comment 3 Timo Sirainen 2005-01-15 19:37:05 EST
It's also possible to create separate plugin packages for pgsql and mysql support. See INSTALL file.
Comment 4 Scot Harris 2005-01-15 19:48:00 EST
Feature creep like this could become very bad.  If the package needs
to be re-architected then so be it.  Such features which are not
required for base level configurations should be supplied as alternate
rpm packages.  

By making it a requirement to include such packages it will make it
more difficult to perform security audits and could expose a system to
potential exploits in packages which normally would not be loaded on a
system.  This should be viewed as a security issue.  Including
packages which are not used means just that much more code on the
system that MIGHT be used as an attack vector.

In addition inclusion of potentially hundreds of such packages is a
bad sign of bloat taking over.  This will increase the foot print of
an install which in turn makes backups cost more.  

IMHO this will hurt admins by increasing the cluter on systems.  

Comment 5 Warren Togami 2005-01-15 19:52:14 EST
I'm not sure if our update process allows adding new sub-packages to existing
packages.  Need to check on that.
Comment 6 Warren Togami 2005-01-15 19:55:30 EST
On second thought, even if it were possible, adding new sub-packages to an
existing distribution during an update would be a bad idea.  Anybody using that
capability would be broken by an automatic update where that ability disappears
from the main package.
Comment 7 Michal Jaegermann 2005-01-15 22:57:50 EST
So far dovecot did not have mysql and postgresql dependencies and
somehow this did not cause a big pain.  OTOH dependency right now
requires not some small library but explicitely postgresql and
mysql in toto.  If I would desire a "kitchen sink and more" imapd
server then I would install cyrus-imapd with all headaches this
implies (not in installation but in maitenance).  Otherwise I probably
have a use, and possibly also a space, for something smaller.
Bringing in big databases defeats that not mentioning possible
security implications.

I violently agree with a comment #3 that such extra capabilities
should be provided by extra plugins.
Comment 8 Warren Togami 2005-01-15 23:08:33 EST
The current package candidates posted by John Dennis as I indicated in
Bug 143707 are wrong in explicitly requiring "postgresql".  With that
removed, rpm auto-dep only pulls in libpq which is only the client

As I wrote in Comment #6, it is even worse of an option to split
sub-packages in an existing distribution package update because that
is guaranteed to break people who use that functionality.  A package
update should theoretically never require manual intervention.  We
cannot split the package in FC2 and not split the package in FC3,
where it would cause trouble for exisiting users.

This leaves the two options outlined in Comment #1.
Comment 9 Scot Harris 2005-01-15 23:23:13 EST
Then how about planning on splitting this in FC4?  Leave it as is in
FC2 and FC3 per the reason you stated.  But get it fixed for future

Comment #7 states it very well, dovecot was the "small simple" option
for providing pop3 and IMAP services compared to cyrus.  

And I still think this puts admins in a poor security stance being
forced to pull in such large packages.
Comment 10 Warren Togami 2005-01-15 23:45:14 EST
Security and extra cruft are poor arguments for splitting the package.
 Red Hat and Fedora have always pulled in lots of libraries that only
some people need.  (Like you cannot remove kerberos from a minimal
desktop install despite almost nobody using it.)  If you are upset by
this, then you are not a target user of the distribution and may be
happier using another distributions.

This being said, it may be a good idea to split dovecot-mysql and
dovecot-postgresql for FC4 because of the php precedent.  We need to
think more about this.

There seems to be extra confusion here like Michal in Comment #7
because of the incorrect artificial dependency of "postgresql" in the
latest candidate packages.  That is definitely not needed and far more
of a problem than a dependency on the client library.

For the moment the decision that must be made is what to do about the
upcoming dovecot update for FC2 and FC3.  My current opinion is
leaning towards making FC2 match the original FC2 dovecot in
dependencies.  This means removing those dependencies.  FC3 original
had it, so those dependencies should remain.
Comment 11 Scot Harris 2005-01-16 12:57:34 EST
Security is a poor argument?  Sounds like something Microsoft would
say.  :) 

From what I could see the dependancy is pulling in more than a few
client libraries, it is pulling in the entire mysql and postgresql
packages.  That is what I feel is wrong.

Splitting this per the php precedent in FC4 is an excellent idea. 
That gets things where they should be.  Leaving things as is in FC2
and FC3 is fine as long as FC4 is changed the correct way.
Comment 12 Warren Togami 2005-01-16 15:15:00 EST
> Security is a poor argument?  Sounds like something Microsoft
> would say.  :)

No, they wouldn't outright say it.  They would only imply it.

Security is a poor reason for your argument, it almost does not apply
at all.
Comment 13 Matthew Miller 2005-01-17 02:04:46 EST
Warren, with all due respect, I think you're mistaken. There can be
exploitable bugs in all sorts of surprising places, so keeping
unneeded code from being installed is a worthy goal and shouldn't be

Now, arguing that there's other factors that make this practically
imposible for FC2 or FC3 is reasonable. But if this *could* be done
right for FC4, it *should* be.
Comment 14 Nicolas Mailhot 2005-01-17 07:46:49 EST
+1 for splitting the db parts.

And btw this is a very common FC packaging problem - it'd be great if
the build system sent a big warning the first time a package goes from
0 deps to severag dozens of deps. It's always easier to separate from
the beginning than untangle stuff months later.
Comment 15 Michal Jaegermann 2005-01-17 11:35:56 EST
Just to remind everybody.  My original report was about "devel" for
FC4 where dependencies of dovecot on mysql and postgresql were not
specified until now; and which did not make that server less

I happen to run dovecot in a production with quite a bit different
codebase so I was not aware about entaglements in FC2 and FC3.
Comment 16 John Dennis 2005-01-17 13:40:57 EST
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.

Comment 17 Matthew Miller 2005-01-17 13:42:33 EST
Thanks. That sounds like exactly the best course of action.
Comment 18 Scot Harris 2005-01-17 14:39:39 EST
Reference to comment #16, Thank you!  That is a very acceptable course
of action and much appreciated.  Hopefully this will become the
precedent for similar situations in the future.
Comment 19 John Dennis 2005-01-17 15:41:59 EST
Here are a couple of new rpms you can grab now (feedback appreciated)

This is a new rpm for FC2, it removes the building of mysql and
postgres support, it also resets the config file to force mbox_locks
to fcntl only (previous behavior).


This is a new rpm for FC3, it continues to build mysql and postgres
support but only has dependencies on the client libraries (previous
behavior), it also resets the config file to force mbox_locks to fcntl
only (previous behavior).

Comment 20 Rahul Sundaram 2005-08-12 20:35:47 EDT
I tried this out with today's rawhide, this is what happens 

 dovecot                 i386       0.99.14-6.fc5    development       680 k
Installing for dependencies:
 mysql                   i386       4.1.12-2         development       2.8 M
 perl-DBI                i386       1.48-4           development       571 k
 postgresql-libs         i386       8.0.3-1          development       180 k

Has the split up packages reached the development tree?

Comment 21 John Dennis 2005-08-12 22:53:51 EDT
No, it turned out to be harder to get the build to produce loadable modules than
it first appeared. I've been deferring this till we ship a 1.0 version rather
than the current 0.99 version.
Comment 22 Petr Rockai 2006-01-23 04:07:34 EST
*** Bug 145371 has been marked as a duplicate of this bug. ***
Comment 23 Petr Rockai 2006-01-23 04:15:00 EST
I will try to get this resolved for FC5, which is currently updating dovecot  
to 1.0 beta 2. After that, i will see what can be done with the database  
Comment 24 Petr Rockai 2006-02-09 04:38:43 EST
Turns out 1.0 transition will be complicated enough as it is, without    
splitting packages. Making this issue an FC6Target. 
Comment 25 Tomas Janousek 2007-06-12 06:29:58 EDT
The sql split is now in rawhide.
Comment 26 Tomas Janousek 2007-08-10 08:17:55 EDT
And the split of auth modules as well, closing.

Note You need to log in before you can comment on or make changes to this bug.