>> proftpd-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) >> proftpd-ldap-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) >> proftpd-mysql-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) >> proftpd-postgresql-1.3.2-0.4.rc3.fc11.i586.rpm (info) (download) > > Again, I'm not sure how this makes it much easier for people packaging. > Even if you went with the module system, you'd have to compile each > module seperately. The packages above, even at the very least, provide > a new module. The same could be done by ./configure > --enable-auth-module=x > && make. > Matt,
The trick here is that by separating out the back-end authentication schemes into modules, you can provide a single source build for package maintainers, which will generate multiple component packages for the whole setup. Then they don't have to maintain separately configured source trees and builds for each authentication module, but can do a single build that can be configured at runtime to use any available (i.e., installed) module. The user then can install just the module(s) that they want and configure them at will without having to uninstall and then install the new package. > If you were to provide authentication packages for vpopmail, they'd > replace > libvpopmail and the binaries. For the 5.5 tree, you can link against the > shared object files if you choose to as well, meaning packages would only > need to replace libvpopmail.so, or even just a symlink to a different > library. > Again, the authentication modules would be removed from libvpopmail.so, and libvpopmail.so would load the appropriate library (e.g. libvpopmail_<authtype>.so) based on the vpopmail configuration. > Modules are not out of the question, but I'm not shooting for them in the > near > future. vpopmail as a project just doesn't need them very badly right > now. > I think that depends on the direction that you want to take vpopmail in. If you're just aiming to update the code, fix bugs, and add needed functionality, then you're probably right. If you're looking to expand the scope of vpopmail usage and deployments (which binary packages will inevitably do as users who don't want to custom-compile things start making use of it), then modularizing the authentication systems is probably the second most important thing to do, after fixing any bugs that might be lurking in the code right now, especially in the back-ends. Also, by creating a modular vpopmail-backend API, you could even break the authentication components out of the vpopmail code tree so that other people could easily maintain and even add new back-end support. Again, I don't know what your goal is, so that will certainly influence how you want to prioritize things. > If someone wants to write a patch against the 5.5 tree, I'll look into it > and > if the code is done well, I will consider adding it, but it was not in my > plan > for 5.5. Fair enough. I can't remember if you've done it or not, but if you haven't you might want to consider posting a to-do/wish list/roadmap for vpopmail development so that people can assist with and/or comment on where things are going. Thanks for working to make vpopmail better! Josh Joshua Megerman SJGames MIB #5273 - OGRE AI Testing Division You can't win; You can't break even; You can't even quit the game. - Layman's translation of the Laws of Thermodynamics j...@honorablemenschen.com !DSPAM:49c1187a32689657416453!
