[pkg-squid-devel] squid-3.5.5 package

[Amos Jeffries]

On 15/07/2015 12:01 p.m., Luigi Gangitano wrote:
> Hi Amos,
> 
> I finally took some time to look into your packages and prepare an upload to fix the libecap transition. I mostly like the way you organized the new squid packages but have some questions:
> 
>   - I see that you didn’t remove /usr/lib/squid3, even if it’s empty, is this intentional? What is the rationale for it?

It wasn't intentional to leave it as a dir. It should be a symlink to
/usr/lib/squid now so the admin can continue to use squid3 config with
helpers while we sort out the squid.conf auto-updates (or not).


>   - cache_dir wasn’t changed and I still have the original /var/spool/squid3 with the data. Do you plan to handle the change? Since the format didn’t change from 3.4 it should work, right? If I recall correctly squid 2.7 had different format, so there would be no reason to keep the original one.

I was following the example of both existing packages there. On removal
both leave the cache_dir folders as-is for manual cleanup. Its also a
bit tricky to tell which directory is in the squid.conf after maint
script has done its thing.

I'm also aware of some people coming to upstream with many GB or TB of
data in caches they dont want to lose.

>   - I probably got into the same problem with dpkg testing and ended with only a pristine /etc/squid/squid.conf. I’ll do some more tests using apt-get (aptitude is sort of deprecated ATM), but it deleted my original squid.conf from squid3 and there is no way to get it back. We may want to put some tests around dpkg-maintscript-helper to avoid that.

Yes it sounds like it. The permutation of both installed and
squid3/squid.conf edited does that when using dpkg manually with the new
squid3 dummy package.

I had to setup a local repository with UNRELEASED package. Then run
every permutation of squid, squid3, squid+squid3 and a test modification
at the top of squid.conf for neither, one or both.

With that normal repo based upgrade aptitude [and I assumed apt-get] did
something fancy by removing squid3 package first (leaving the /etc and
/var/spool alone), installing new squid (which shuffles the configs
around), then finishes removing squid3 (leaving /etc if not empty).
Which turns out exactly like we want with altered squid3 files in
/etc/squid/squid.conf - including custom user-created config files.


>   - squid3-common did not get removed. I see that squid-common conflicts with itself but not with squid3-common. Did you mean to change this?

Missed that sorry. aptitude removes no longer needed auto-installed /
dependency packages.

>   - I could not check, but what happens if squid.conf from squid3 contains some pointer to helper binaries in /usr/lib/squid3? Does it fail to start?	
> 

If the binary is missing yes. So /usr/lib/squid3 should be a symlink to
/usr/lib/squid for now.


>> Il giorno 13/giu/2015, alle ore 08:18, Amos Jeffries ha scritto:
>>
>> When users have both squid and squid3 packages installed prior to
>> upgrade there is a bit of script guesswork about which squid.conf to use
>> on the end product. They will need to manually check the results OR,
>> just manually purge whichever package they dont want to use before upgrade.
> 
> We may just make a note in NEWS.Debian about this.
> 

Ok.

Amos