What I've done in the past for something like this is to make the conversion part of the rc.d script as an extra command, make the "start" command check for the presence of the old config file and output a big warning, and add an INSTALL script that checks for the old file and also gives a big warning.
It's hard to come up with a good general system for managing these issues because people manage their config files in so many ways, and we don't have a pkgsrc-approved method that all packages are forced/encouraged to adhere to. Just don't over-complicate it for users.
-- Johnny C. Lam
On Oct 26, 2010 9:07 AM, "Geert Hendrickx" <ghen%telenet.be@localhost
> On Tue, Oct 26, 2010 at 08:56:30AM -0400, Greg Troxel wrote:
>> Your example made me think, I could perhaps just add Dovecot 2.0 as a new
>> mail/dovecot2 package (also since dovecot 1.x is still supported).
>> That will prevent issues with automated/unattended updates, and a warning
>> MESSAGE will be sufficient.
>> Seems ok, but really no one will want to have both installed, and they
>> will CONFLICT. So starting dovecot-2.x via rc.d and having it upgrade
>> park would still be great (I like your rc.d idea). That said, it's of
>> course not fair of me to tell you to write the code.... Plus, a
>> dovecot-2 with a warning and upgrade code later is still a big step
> I'm still considering both options, however my suggestion was in analogy
> with Postgresql, of which we also have several conflicting versions in
> pkgsrc. The goal there is not to be able to install them in parallel, but
> give users the choice between (major) versions. There are other examples
> in pkgsrc; apache, bind, mysql.
> Geert Hendrickx -=- ghen%telenet.be@localhost
-=- PGP: 0xC4BB9E9F
> This e-mail was composed using 100% recycled spam messages!