[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: handling moved configuration files
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
hope all this feedback is useful. :)
Main Index |
Thread Index |