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): dovecot-0.99.13-2.devel
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 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.
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 security implications. 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 library. 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 versions. 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 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.
> 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.
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 dismissed. 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 functional. 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). ftp://people.redhat.com/jdennis/dovecot-0.99.13-4.FC2.i386.rpm 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). ftp://people.redhat.com/jdennis/dovecot-0.99.13-3.FC3.i386.rpm
I tried this out with today's rawhide, this is what happens Installing: 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 support.
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.