Tom Collins wrote:

i respect charles and his opinion about .qmail and .vpopmail files... but making charles happy is not a primary goal of vpopmail, and it's certainly not an excuse to unsafely force this change on all of the existing vpopmail systems out there. i think it makes more sense to explain the situation to the administrators, provide them with a tool to manually rename the files en masse (and identify any problem cases where both .qmail and .vpopmail files already exist) and TELL them that it should be done- but the final decision about whether and when to do the change should be left in the hands of the administrator of each system.

of course i would also remove the "either/or" filename logic from the NEXT version of vpopmail, so that if they haven't renamed the files, they become broken and it's their own fault.

How about this -- make it a configure option. People who want to call them .vpopmail can choose that option and run the tool to do the conversion. People who want to continue using .qmail (like me) can easily do so.

I do plan a configure option.

Seriously, I don't see any advantages for vpopmail admins to use .vpopmail instead of .qmail, other than it makes clear which files are parsed by .qmail-local and which are parsed by vdelivermail.

I agree the benefits are small. If the configure option doesn't default to on, we should not do this at all. Its the people who won't read the configure options list who need it turned on.

i've already written pseudo-code for the framework of each maintenance operation, the only thing preventing me from turning that into real working code at this point is free time, and the lack of a consensus about how it will be handled (i.e. i don't want to write code which won't actually be used.)

if there are users out there who NEED to have the alias lines stored in their database back-ends, we CAN make that happen. granted, it means more coding and more testing, which means it'll probably take a little longer to finish, but if it makes the program usable to more people, isn't that the important thing?

I've pictured this in my head as well, and I agree with John that we should add a sequence field to the existing table, then add the tools to support it properly.

Yes there will be a sequence field in the table. The question is how do we add the tools. Do we break the existing alias interface, or do we provide an alternate interface for when order is important, leaving all existing code intact. I'm working on a reply to John on this, but it may be a day or two...

Reply via email to