[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Best practice for squid 2.x-3.x migration

Hi all,

I need some advise from more experienced maintainers on the migration process from current (2.7) squid packages to the new (3.3) squid3 packages. Until now, since there was no complete feature compatibility between the two, base packages (squid{,3}{,-common,-dbg}) have been kept separated and configuration files have been placed in different locations (/etc/squid and /etc/squid3).

In a near future squid3 will be team maintained and we're discussing how to handle this transition. Migration use-cases are:

1. admin has squid (2.x) installed and no squid3 and wants to move his 2.x configuration over to 3.x;
2. admin has both squid version installed and wants to keep one.

We would like to automate migration as much as possible and I see two options other the let the admin do its thing, right now:

1. keep squid3 as it is and handle the two migration use-cases in a new, temporary release of squid binary from squid sources which should depend on squid3, do the migration work (moving/parsing/replacing configuration files) in pre/post-inst (need help here) and be left to be removed once migration is over (Moritz Mühlenhoff suggested this one using openoffice.org as an example), or
2. make squid depend on squid3 and provide migration scripts in a release of squid3 which checks for squid existence in a developer script (config, pre-inst?).

I would really appreciate to hear your suggestions and experience on this subject.



Luigi Gangitano -- <luigi@debian.org> -- <gangitano@lugroma3.org>
GPG: 1024D/924C0C26: 12F8 9C03 89D3 DB4A 9972  C24A F19B A618 924C 0C26
GPG: 4096R/2BA97CED: 8D48 5A35 FF1E 6EB7 90E5  0F6D 0284 F20C 2BA9 7CED

Reply to: