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):
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.
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.
It's also possible to create separate plugin packages for pgsql and mysql support. See INSTALL file.
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
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.
I'm not sure if our update process allows adding new sub-packages to existing
packages. Need to check on that.
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.
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
I violently agree with a comment #3 that such extra capabilities
should be provided by extra plugins.
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.
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.
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.
Security is a poor argument? Sounds like something Microsoft would
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.
> 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
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.
+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.
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.
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.
Thanks. That sounds like exactly the best course of action.
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.
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).
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?
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.
*** Bug 145371 has been marked as a duplicate of this bug. ***
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
Turns out 1.0 transition will be complicated enough as it is, without
splitting packages. Making this issue an FC6Target.
The sql split is now in rawhide.
And the split of auth modules as well, closing.