Re: handling moved configuration files

[George Georgalis <george%galis.org@localhost>]

On Wed 27 Oct 2010 at 04:40:32 PM +0200, Geert Hendrickx wrote:
>On Wed, Oct 27, 2010 at 09:32:34AM -0500, Larson, Timothy E. wrote:
>> Does pkgsrc have a general policy for handling multiple concurrently-
>> support major versions of packages?  
>> 
>> Seems to me that when version X+1 of package bar/foo comes out, that we
>> should create bar/fooX (if we need to maintain support for the old one)
>> and let bar/foo be the new one.  I, too, think it makes sense that if you
>> want the latest and greatest foo, you should be able to just install
>> bar/foo and have it.  If someone knows he needs an outdated version, then
>> the responsibility for tracking the version numbers should fall on him.
>
>
>
>This discussion is deviating from the moved/renamed config files topic.
>
>
>Also, the idea behind introducing mail/dovecot2 here was exactly to ensure
>admin interaction for the Dovecot 1.2->2.0 update (by having to install a
>new package rather than just upgrading) so that the moved config file would
>not be unnoticed.

I think it is a great idea to provide tools to install/upgrade config files
but I don't think it should be done automatically.

the more I think about it the more problems I see with migrating a "package"
to a meta package pointing to the new major release name, eg "package2"
I don't like what I suggested before.

if a new meta package "package-rel" where used to track the major
releases, I would try it verses going to package2. if I got a message
"package-rel" conflicts with "package-rel" during an upgrade, that
could be confusing. but I guess what I would see is "package2"
conflicts with "package" and then remove "package" before installing
"package-rel"

hope all this feedback is useful. :)

-George