Re: [vchkpw] Re: vpopmail FHS compliance
Itamar Reis Peixoto wrote: that's a great , but qmail is no more maintaned (no new features) no new features in qmail for 10 years... because it rocks! :) I'm sure, community will repack qmail soon to simplify things. !DSPAM:49c281b332685987920984! begin:vcard fn:Dmitry Dvorkin n:Dvorkin;Dmitry org:Take Over The World Inc;Evil Solutions adr:;;;Tver;;170001;Russia email;internet:dvor...@flightmedia.ru title:Dr Evil x-mozilla-html:FALSE url:http://dvorkin.tvernet.ru version:2.1 end:vcard
Re: [vchkpw] Re: vpopmail FHS compliance
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!
Re: [vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Megerman wrote: 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. I see. That makes a bit more sense. I don't maintain any binary package distributions, so I'm not really familiar with the process. My assumptions about it were incorrect I guess :) 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! I'll probably look into what it will take to move the authentication backends into modules for the 5.5 branch. Thanks for your input. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknBIrAACgkQ6QgvSNlBT3D/BACfWi1UUu9Mc0L6KjanRqS4kx/B NlQAoKD3/VcrThiVtf6Dvf9ifeR6vfGn =C6Er -END PGP SIGNATURE-
Re: [vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Itamar Reis Peixoto wrote: Josh thanks for explaining the things for me, my english is not good making vpopmail support loadable module support will bring vpopmail into linux distros (fedora, opensuse, mandriva) and probably others and make the vpopmail userbase grow. I appreciate your input. I'm just not very familiar with binary distribution maintenance. I will be looking into this further. Thanks! - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknBIwAACgkQ6QgvSNlBT3B0rwCgpjypmND3h9aDEmareRWcwHCN tfoAniZdGJs0pvzUNtf6AeQ4My+zs+7L =jfMG -END PGP SIGNATURE-
Re: [vchkpw] Re: vpopmail FHS compliance
Josh thanks for explaining the things for me, my english is not good You're welcome. making vpopmail support loadable module support will bring vpopmail into linux distros (fedora, opensuse, mandriva) and probably others and make the vpopmail userbase grow. Well, that's a rather simplified statement. After all, since vpopmail is currently tied to qmail, you also have to get qmail into the linux distros, and while much easier now that qmail is Public Domain, it's still not as simple as that given the current state of qmail and patches. But it is a step in that direction... 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:49c131df32681438719974!
Re: [vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Joshua Megerman wrote: 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. I see. That makes a bit more sense. I don't maintain any binary package distributions, so I'm not really familiar with the process. My assumptions about it were incorrect I guess :) No problem - I don't do any package maintenance myself either, but it's always frustrated me that vpopmail could only support one back-end at a time, and that it was allmost all configured at compile-time... 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! I'll probably look into what it will take to move the authentication backends into modules for the 5.5 branch. Thanks for your input. You're welcome - I don't have a lot of time for coding these days, but I've invested enough time in qmail/vpopmail that I want to see them succeed :) 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:49c132a332681600362347!
Re: [vchkpw] Re: vpopmail FHS compliance
that's a great , but qmail is no more maintaned (no new features) will be a good ideia to make vpopmail more compatible with postfix and maybe others MTA's Well, that's a rather simplified statement. After all, since vpopmail is currently tied to qmail, you also have to get qmail into the linux distros, and while much easier now that qmail is Public Domain, it's still not as simple as that given the current state of qmail and patches. But it is a step in that direction... Josh Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 !DSPAM:49c133e932681336914356!
Re: [vchkpw] Re: vpopmail FHS compliance
that's a great , but qmail is no more maintaned (no new features) will be a good ideia to make vpopmail more compatible with postfix and maybe others MTA's Ad that, my friend, is a horse of a totally different color. To the best of my knowledge there is no plan to make vpopmail work generically with MTAs other than qmail (Matt, please correct me if I'm wrong), as it currently is integrated rather tightly with how qmail does things. While I'm not disagreeing that expanding vpopmail's compatibility with other MTAs would expand it's acceptance, I also don't really see it happening without a complete internal rewrite to how vpopmail does things. Maybe something to roadmap for vpopmail 6? In any case, I wouldn't hold my breath :) 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:49c13c2332681437819685!
Re: [vchkpw] Re: vpopmail FHS compliance
Itamar Reis Peixoto wrote: that's a great , but qmail is no more maintaned (no new features) will be a good ideia to make vpopmail more compatible with postfix and maybe others MTA's Qmail is now in the public domain. You are free to add any new features you want. Regards, Rick !DSPAM:49c13c5f32681609681472!
Re: [vchkpw] Re: vpopmail FHS compliance
On Sat, March 14, 2009 10:30 am, aledr wrote:
On Sat, Mar 14, 2009 at 2:03 PM, Matt Brookings m...@inter7.com wrote:
*snip*
We've had the same sort of concerns regarding FHS compliance (and
eas-of-package-building) for some time, and have had a set of patches
within our RPM that have proved effective for us. I have not tested them
with 5.4.28, however... I'd be grateful to anyone who could do (especially
in isolation from our other patches).
They might be useful for others on the list as well. Details below.
Regards,
Japheth Cleaver
# Instead of vpopmail's home directory, use standard FHS locations:
# bindir, localstatedir, and sysconfdir for files (patches configure.in
and code)
Patch1: vpopmail.use-std-locations.5.4.19.patch
# Modify makefile to deal with our above changes (patches Makefile.am)
Patch2: vpopmail.use-std-locations-makefile.patch
# Documentation changes for patches 1 and 2
Patch3: vpopmail.use-std-locations-documentation.patch
# Make vpopmail's configure rpmbuild-friendly
vpopmail.no-root-needed.patch
# Don't verify that the qmail binaries are actually installed
# at configure time
vpopmail.configure-no-qmail-needed.patch
# Same goes for tcpserver/tcprules
vpopmail.configure-no-tcprules-needed.patch
# Look in /usr/{s}bin before /usr/local or {qmailHome}/bin when finding
# tcprules and qmail binaries
vpopmail.configure-search-paths.patch
# Ensure that all checks for libs are compatible with x86_64 (/usr/lib64)
Patch11: vpopmail.x86_64libs.patch
# Why are mysql libs being checked using the same variable as libdir?
Patch12: vpopmail.sanemysqllibs.patch
!DSPAM:49c00f8e32685742672204!
vpopmail.use-std-locations.5.4.19.patch
Description: Binary data
vpopmail.use-std-locations-makefile.patch
Description: Binary data
vpopmail.use-std-locations-documentation.patch
Description: Binary data
vpopmail.no-root-needed.patch
Description: Binary data
vpopmail.configure-no-qmail-needed.patch
Description: Binary data
vpopmail.configure-no-tcprules-needed.patch
Description: Binary data
vpopmail.configure-search-paths.patch
Description: Binary data
vpopmail.x86_64libs.patch
Description: Binary data
vpopmail.sanemysqllibs.patch
Description: Binary data
Re: [vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Japheth Cleaver wrote: On Sat, March 14, 2009 10:30 am, aledr wrote: On Sat, Mar 14, 2009 at 2:03 PM, Matt Brookings m...@inter7.com wrote: *snip* We've had the same sort of concerns regarding FHS compliance (and eas-of-package-building) for some time, and have had a set of patches within our RPM that have proved effective for us. I have not tested them with 5.4.28, however... I'd be grateful to anyone who could do (especially in isolation from our other patches). I'm currently working on adding FHS compliance to the 5.5 branch. 5.4 is frozen to everything except bugfixes. FHS compliance should find it's way into the first development version of the 5.5 branch. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAEd4ACgkQ6QgvSNlBT3CWHwCdFVyw2aJ5LcuToxZeBHsnunpN y8IAniPRmGRZQbly1uq+jAtygMnbRft7 =k32g -END PGP SIGNATURE-
Re: [vchkpw] Re: vpopmail FHS compliance
Also will be a good idea to have loadable module support for databases mysql sqlite pgsql cdb etc... this will make packaging easy I'm currently working on adding FHS compliance to the 5.5 branch. 5.4 is frozen to everything except bugfixes. Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 !DSPAM:49c022ce32681229813388!
Re: [vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Itamar Reis Peixoto wrote: Also will be a good idea to have loadable module support for databases mysql sqlite pgsql cdb etc... I'm not sure loadable module support is really all that useful. this will make packaging easy Please explain. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAI3oACgkQ6QgvSNlBT3BTQQCeO51O+8UMuplJKWpNEpXEOygu b8EAnA63JkXggkPtu4guuwaZoZJNqp/y =IvTt -END PGP SIGNATURE-
Re: [vchkpw] Re: vpopmail FHS compliance
please look at fedora proftpd package http://koji.fedoraproject.org/koji/buildinfo?buildID=91270 he have some sub-packages, mysql, pgsql etc.. at current state of vpopmail if we need vpopmail with mysql support, then I need to compile vpopmail and link with mysql librarys if we need vpopmail with pgsql support then I need to recompile everthing with pgsql support. with loadable module support only some parts of the code will be linked with mysql, pgsql, oracle etc.. On Tue, Mar 17, 2009 at 7:26 PM, Matt Brookings m...@inter7.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Itamar Reis Peixoto wrote: Also will be a good idea to have loadable module support for databases mysql sqlite pgsql cdb etc... I'm not sure loadable module support is really all that useful. this will make packaging easy Please explain. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAI3oACgkQ6QgvSNlBT3BTQQCeO51O+8UMuplJKWpNEpXEOygu b8EAnA63JkXggkPtu4guuwaZoZJNqp/y =IvTt -END PGP SIGNATURE- -- Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 !DSPAM:49c02b8f32683208911726!
Re: [vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Itamar Reis Peixoto wrote: at current state of vpopmail if we need vpopmail with mysql support, then I need to compile vpopmail and link with mysql librarys if we need vpopmail with pgsql support then I need to recompile everthing with pgsql support. Right. That's the idea. People don't change their authentication mechanism daily, weekly, or even yearly. They generally pick one and stick with it unless a larger change happens, like scaling up to a clustered environment which generally requires a networked database. Besides, even if people did change their backend database on a more frequent basis, it takes around 5 seconds to recompile vpopmail. About the same time it would take to edit a configuration file to make it load a different authentication module. with loadable module support only some parts of the code will be linked with mysql, pgsql, oracle etc.. Please explain why you would need different parts of vpopmail talking to different databases. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknAL64ACgkQ6QgvSNlBT3ACMgCgiv+uOvjKnq1wqOdcfSfZYFeI C4IAnRHr5BOu2o7VxIhbwe1BMZfS6xvI =iaHP -END PGP SIGNATURE-
Re: [vchkpw] Re: vpopmail FHS compliance
to make it packagable like proftpd http://koji.fedoraproject.org/koji/buildinfo?buildID=91270 fedora compile proftpd only one time and the users have the choice of ldap, mysql and pgsql database. if we need proftpd with mysql then I will install proftpd and proftpd-mysql packages and it will work with mysql. this will make easy for the people to install without recompile. 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) Please explain why you would need different parts of vpopmail talking to different databases. Itamar Reis Peixoto e-mail/msn: ita...@ispbrasil.com.br sip: ita...@ispbrasil.com.br skype: itamarjp icq: 81053601 +55 11 4063 5033 +55 34 3221 8599 !DSPAM:49c030fa32685217169677!
[vchkpw] Re: vpopmail FHS compliance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 aledr wrote: Good day Matt! I do not mind you emailing me privately, but I'd rather see this traffic on the list for people's input as well. I've CC'd the list in my reply. I sent a small patch to the tracker, but It will not work at all. I think you hadn't the time to see yet. You uploaded a patch to the tracker that doesn't work? I've done some deeper changes on my local environment and after contact Timo, he improved the option --with-vpopmail on dovecot to allow the changes to FHS. You can see It here[1]. As I said, the changes will result on an improvement on --enable-non-root-build to not check for vpopmail's user and group and these paths: Binaries will all go to: /usr/bin/* Configuration: /etc/vpopmail/vpopmail.mysql /etc/vpopmail/vlimits.default Libs: /usr/lib(64)/vpopmail/inc_deps /usr/lib(64)/vpopmail/lib_deps /usr/lib(64)/vpopmail/libvpopmail.a Includes: /usr/include/vpopmail_config.h /usr/include/vpopmail.h Domains and user's mailbox: /var/spool/vpopmail/domains My real aim is to provide a clean way to package vpopmail for RPM based distros. I'm already doing It for openSUSE here[2], on my home repo. Can these changes be real on vpopmail or should I just make it myself and keep it with me? I guess my original thoughts with the 'non-root' build were that you would be compiling vpopmail as a non-root user. I have no problems with the FHS compliance options. You cannot use the 'non-root-build' flag for your patch as it is already used to allow someone to build the package when not the root user. I'm just asking it again to avoid spent time sending patches to changes I'll not see on the Inter7's vpopmail and should kept local. I wouldn't mind having the FHS as an option during the build, however, I'd rather it be implemented in a more autotools friendly way where you can set the individual locations of things like the domains directory, include directory, etc. vpopmail currently assumes many of these are subdirectories of it's home directory. Once that assumption has been taken out of play, it would work. So, you'd need options for --enable-bindir=, --enable-etcdir, or what-have-you. Then, finally, you could have an --enable-fhs-compliant which could automatically set these values. Furthermore, these changes will need to be made against the 5.5 tree. 5.4 is frozen with only bug fixes being allowed in. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm7438ACgkQ6QgvSNlBT3DSnQCdFRjVC64C3fPc3wW/yWf0IEuY YrYAoK+vPwLbKw3x9LNH5qWvRbii4fpt =8RSK -END PGP SIGNATURE-
[vchkpw] Re: vpopmail FHS compliance
On Sat, Mar 14, 2009 at 2:03 PM, Matt Brookings m...@inter7.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 aledr wrote: Good day Matt! I do not mind you emailing me privately, but I'd rather see this traffic on the list for people's input as well. I've CC'd the list in my reply. Nice, just remember the vpopmail 6 pages on the wiki. There are a lot of good changes proposed and this question was discussed there already. This[1] link could give a little input to you. I sent a small patch to the tracker, but It will not work at all. I think you hadn't the time to see yet. You uploaded a patch to the tracker that doesn't work? It works, but do not cover all changes proposed on the last sent mail to you. I'm using the patch actually, you didn't check the links, neither the patch... I've done some deeper changes on my local environment and after contact Timo, he improved the option --with-vpopmail on dovecot to allow the changes to FHS. You can see It here[1]. As I said, the changes will result on an improvement on --enable-non-root-build to not check for vpopmail's user and group and these paths: Binaries will all go to: /usr/bin/* Configuration: /etc/vpopmail/vpopmail.mysql /etc/vpopmail/vlimits.default Libs: /usr/lib(64)/vpopmail/inc_deps /usr/lib(64)/vpopmail/lib_deps /usr/lib(64)/vpopmail/libvpopmail.a Includes: /usr/include/vpopmail_config.h /usr/include/vpopmail.h Domains and user's mailbox: /var/spool/vpopmail/domains My real aim is to provide a clean way to package vpopmail for RPM based distros. I'm already doing It for openSUSE here[2], on my home repo. Can these changes be real on vpopmail or should I just make it myself and keep it with me? I guess my original thoughts with the 'non-root' build were that you would be compiling vpopmail as a non-root user. I have no problems with the FHS compliance options. You cannot use the 'non-root-build' flag for your patch as it is already used to allow someone to build the package when not the root user. I'm not, and don't want to use It on my patch, but the non-root-build flag checks against vpopmail's user and group on the system. You can't add users and groups on build environment system (as you aren't root), You should do that when installing the software. See section %pre on the spec file at the sent link[1]. I'm just asking it again to avoid spent time sending patches to changes I'll not see on the Inter7's vpopmail and should kept local. I wouldn't mind having the FHS as an option during the build, however, I'd rather it be implemented in a more autotools friendly way where you can set the individual locations of things like the domains directory, include directory, etc. vpopmail currently assumes many of these are subdirectories of it's home directory. Once that assumption has been taken out of play, it would work. Right. If you had time to look at the patch sent, You could saw these changes. So, you'd need options for --enable-bindir=, --enable-etcdir, or what-have-you. Then, finally, you could have an --enable-fhs-compliant which could automatically set these values. Furthermore, these changes will need to be made against the 5.5 tree. 5.4 is frozen with only bug fixes being allowed in. - -- /* Matt Brookings m...@inter7.com GnuPG Key D9414F70 Software developer Systems technician Inter7 Internet Technologies, Inc. (815)776-9465 */ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm7438ACgkQ6QgvSNlBT3DSnQCdFRjVC64C3fPc3wW/yWf0IEuY YrYAoK+vPwLbKw3x9LNH5qWvRbii4fpt =8RSK -END PGP SIGNATURE- [1]: http://vpopmail.wiki.sourceforge.net/Makefile+changes+(for+RPMs) Thanks. -- [ ]'s Aledr - Alexandre OpenSource Solutions for SmallBusiness Problems !DSPAM:49bbe9a932682140219975!
