Bug#858556: In case the code is not anywhere...
On 26/03/2017 1:34 p.m., Santiago Garcia Mantinan wrote: >> Maybe it was just that the original code had to be at the >> upgrade|install-upgrade >> block of the case? >> >> But why is the -d /etc/squid3 checked? > IIRC this is for transitions where _both_ squid and squid3 packages are already installed. Including the odd situation where a squid3 package is partially installed, which apt seems to like doing. The root cause of our troubles AFAICT is that the old 2.x "squid" packages do not register their squid.conf as a conffile. So in the debci testing dpkg has no way to know that there were no changes to the 2.7 default config file when upgrading wheezy->stretch. That was the initial bug 801654 problem about constantly asking to preserve changes. So... the current squid package unconditionally preserves any old squid.conf, goes on to install and register the 3.5+ squid.conf.default file as its baseline conffile. Then slips the old squid.conf into place as if it had gone through a normal conffile upgrade with no questions, always preserving the 'old' version squid.conf. That much seems to be working as intended for upgrades. But I/we wrongly assumed the --compare-versions would return false if there was no previous version. Amos
Bug#858556: In case the code is not anywhere...
> Maybe it was just that the original code had to be at the > upgrade|install-upgrade > block of the case? > > But why is the -d /etc/squid3 checked? I followed this two questions doing some tests on my system and it looks to me as we should be happy with this patch: --- /tmp/squid.preinst 2017-03-26 01:27:31.201012140 +0100 +++ debian/squid.preinst2017-03-26 00:59:34.433577481 +0100 @@ -26,6 +26,8 @@ /etc/squid3/errorpage.css /etc/squid/errorpage.css 3.5.4-1~ squid3 -- "$@" fi +case "$1" in + upgrade|install-upgrade) # # If the squid (2.7) package was being used previously protect # the squid.conf file, which was not tracked as a conffile. @@ -34,12 +36,9 @@ # Except when a squid3 package was used, since we do want the # debconf questions to appear as the packages get merged. # -if dpkg --compare-versions "$2" lt '2.8' && test -d /etc/squid3; then +if dpkg --compare-versions "$2" lt '2.8'; then mv /etc/squid/squid.conf /etc/squid/squid.conf.pre3.5_upgrade fi - -case "$1" in - upgrade|install-upgrade) ;; abort-upgrade) exit 0 Which basically means to move the check to the upgrade|install-upgrade section and remove the check for the squid3 dir. My tests of both an upgrade from 2.7 and from jessie's squid3 work ok. Amos, I don't know what your idea with this code was, so I'd like to talk about it a bit before uploading a new version. Regards. -- Manty/BestiaTester -> http://manty.net
Bug#858556: In case the code is not anywhere...
> Just in case you didn't have it and if I understood it well... I came up > with this in a quick attempt: Did I say this was just a quick attempt? Maybe it was just that the original code had to be at the upgrade|install-upgrade block of the case? when you are on an upgrade the parameters are for example: upgrade 2.7.STABLE9-4.1+deb7u2 3.5.23-2 But why is the -d /etc/squid3 checked? if we had the /etc/squid3 dir, then doesn't it mean that we had squid3 package around? I don't get this part. Maybe it is just too late, time to go to bed. Regards... -- Manty/BestiaTester -> http://manty.net
Bug#858556: In case the code is not anywhere...
> So... I guess you had some code that is missing here, isn't it? Just in case you didn't have it and if I understood it well... I came up with this in a quick attempt: V="$(dpkg --status squid 2>/dev/null|sed -n "s/^Version: \(.*\)/\1/p")" if [ -n "$V" ] && dpkg --compare-versions "$V" lt '2.8' && test -d /etc/squid3; then mv /etc/squid/squid.conf /etc/squid/squid.conf.pre3.5_upgrade fi Regards... -- Manty/BestiaTester -> http://manty.net