Wednesday 4 January 2017

Re: Your squid3 changes in 3.5.12-1ubuntu4

Hi Robie,

On Wed, Jan 04, 2017 at 04:39:14PM +0000, Robie Basak wrote:
> I'm working on a merge of squid3. I've understood most of your changes
> in 3.5.12-1ubuntu4, but am having trouble following a few small pieces
> of it. Please could you advise so that I make sure I don't drop anything
> and can send useful patches up to Debian that I can explain?

> You can see your upload and how I've broken it down in
> https://git.launchpad.net/~racb/ubuntu/+source/squid3/log/?id=6c013d1b5caffaed001efd71675b5cfca38188a9
> - specifically b9c275e..6c013d1.

> I've matched pieces of your complete patch with your individual
> changelog entries, but I'm struggling to complete the matching.

> Specifically:

> * I'm not sure if I've matched
> https://git.launchpad.net/~racb/ubuntu/+source/squid3/commit/?id=6fd2b083c6ae6c85c1d7a7a9f9b49ae8a5cfba76
> correctly. If this is wrong, can you tell me what adding that line
> achieves please, or which other changelog entry it belongs to?

This line was a replacement for the following block originally in the Debian
maintainer script:

- # Stop squid3 daemon and remove init script links
- #
- if test -x /etc/init.d/squid3 ; then
- invoke-rc.d squid3 stop
- update-rc.d squid3 remove >/dev/null
- fi
-fi

If the 'update-rc.d squid3 remove' call has been removed now in Debian, we
can also drop this from the Ubuntu delta. This was all upgrade handling
from the old squid3 init script, which is obsolete now as of 16.04.

> * Was
> https://git.launchpad.net/~racb/ubuntu/+source/squid3/commit/?id=691d4d29ee3578d9801f28f1f45c81e53fe38313
> part of your conffile handling changes? Are you dropping it because
> "dpkg-maintscript-helper mv_conffile" doesn't need the destination
> directory to exist on preinst? If so, is there a specific reason the
> superfluous mkdir would cause a problem that I can explain to Debian
> when sending it up?

At this distance, I don't recall a specific rationale for removing that bit.
I don't know of any reason that it would cause a problem. At that point I
was trying to clear out everything that wasn't needed in order to make the
maintainer scripts comprehensible.

I doubt it's worth forwarding this bit up to Debian as a discrete unit. In
practice, all of this migration code ought to be dropped entirely in Debian
following the next stable release, and should already be no-op code in
Ubuntu post 16.04.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org