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...
