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 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.
>> 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:
>> Domains and user's mailbox:
>> My real aim is to provide a "clean" way to package vpopmail for RPM
>> based distros. I'm already doing It for openSUSE here, on my home
>> 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
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.
>> 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
> Then, finally, you could have an --enable-fhs-compliant which could
> set these values.
> Furthermore, these changes will need to be made against the 5.5 tree. 5.4 is
> 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
> -----END PGP SIGNATURE-----
Aledr - Alexandre
"OpenSource Solutions for SmallBusiness Problems"