[pkg-squid-devel] Squid 4.0

[Amos Jeffries]

On 19/03/2015 12:00 a.m., Luigi Gangitano wrote:
> Hi Amos,
> 
>> Il giorno 18/mar/2015, alle ore 11:39, Amos Jeffries ha scritto:
>> 
>> So, what packaging structure and naming will be used by Debian
>> going forward after freeze is over?
> 
> jessie will be released (hopefully by the end of April) with just
> squid3 in its current form. For the following release (Debian 9
> ‘stretch’) we are free to take the path we prefer.
> 
> Our options are:
> 
> - keep the squid3 package name (and directory layout) and just change
> the version number. This makes sense when you see the squid3 codebase
> as the big move to C++ and future versions still going on the same
> line, or
>

That went through some intense debate amongst the core developers
upstream and consensus was to detatch the version numbers from any
seriously major change meaning like that.

I/we/upstream would prefer downstream distros to reflect that new squid
versions represent only the addition of a few new features.  The
existing arbitrary schedule of monthly bug fix releases with a feature
release every 8-14 months - nothing significant to most users.



> - rename all the squid3* packages back to squid* and move
> everything over. Since there is no direct upgrade path from squeeze
> to stretch, we won’t have any issue with migrations.
> 
>> And roughly what steps need to be done to migrate to it from the 
>> existing squid and squid3 package versions?
> 
> Migrating from squid package is not needed as I outlined before,
> migrating from current squid3 is a matter of moving files around from
> /etc/squid3 to /etc/squid and from /var/*/squid3 to /var/*/squid
> 
> Moving conffiles can be (almost) easily handled with
> dpkg-maintscript-helper. Everything else requires parsing and
> patching squid.conf.

Sweet, that matches the outcome I would like to see.

> 
> Current squid 2.7 should be removed from the archive as soon as
> squeeze is released, I will file a bug for that.

Thats already bug 672156 I thought.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672156>

from my experience with other packages having it gone from the repo does
not cause it to drop from already installed machines. It stays present
at the last version until something conflicts or otherwise forces
removal before the other new thing can be installed.
 So I'm unsure what that removal would gain us exactly when moving the
squid3 package to re-use the name.

> 
> I would like to hear from the group about these (and other) options.

The other options I see are:

 - making "squid" a transitional package that pulls in whatever squidN
package is available.
  Which is a bit nasty as we still have lots of diff from upstream and
Ubuntu downstream on the per-version packages.

 - making both existing packages provide the same squid-3.5 version and
advising people to migrate if they have both installed.

 - making squid package provide 3.5 version with auto-upgrade, and
Provides:squid3
 The auto-upgrade operations are essentially the same for both base
version, just more of it.



> 
> Regards,
> 
> L
> 
> P.S. For the squeeze Release Notes, we should write a short summary
> of actions needed to move over from squid 2.7 to squid3.

Yes. One of you with DD access will need to do that.

There are some surprises with the long jump. The noticable differences
are the same in the jump from 3.1.20 to 3.4.8 within the Jesse squid3
package itself.

Things to mention:
- the helper renaming (squid 3.2 release notes),
- auto-defined ACLs (manager, localhost, to_localhost, all),
- COSS replaced with Rock and version in Debian limited to storing 32KB
objects,
- behaviour changes visible in logs and HIT/MISS as Squid goes from
HTTP/1.0 to HTTP/1.1 behaviour,
- Host header verification on interceptors and associated forwarding
loop issues if NAT is done on a remote machine (squid 3.2 release notes),


Amos