Re: Standards 4.1.3 and apt-cacher

[Felipe Sateler <fsateler@debian.org>]

Hi,

On Wed, 07 Feb 2018 10:14:15 +0000, Mark Hindley wrote:

> Hello,
> 
> I am trying to upgrade apt-cacher to Standards version 4.1.3. In
> particular using DISABLED=yes|no in /etc/defaults is now prohibited.

Thanks for fixing this.

> 
> apt-cacher can be run as a daemon or from /etc/inetd.conf and this
> configuration is set in response to a debconf question.
> 
> I have a working version of the postinst which I believe complies with
> the new policy by no longer changing a value in /etc/default/apt-cacher,
> however it contains multiple calls to update-rc.d (one to register the
> init file and then calls to enable/disable as appropriate in response to
> db_get). This produces the lintian error:
> duplicate-updaterc.d-calls-in-postinst.
> 
> Is my approach flawed or is lintian being overzealous?

It is a bit overzealous, but I think you have another problem. Your 
package will override local admin on upgrades (if they changed the config 
manually) by calling update-rc.d and update-inetd. I think you need to 
change it to not do so. I don't know much about update-inetd but the 
pattern for update-rc.d should be something like this:


if [ $1 = configure ] || [ $1 == abort-upgrade ] ; then
  db_get apt-cacher/mode
  case "$RET" in
    daemon)
      update_rc_args="apt-cacher defaults"
      ;;
    inetd)
    manual)
      update_rc_args="apt-cacher defaults-disabled"
      ;;
  esac
fi

if [ $1 = reconfigure ] ; then
  db_get apt-cacher/mode
  case "$RET" in
    daemon)
      update_rc_args="apt-cacher enable"
      ;;
    inetd)
      update_rc_args="apt-cacher disable"
      ;;
    manual)
      update_rc_args="" #do nothing
      ;;
  esac
fi

if [ -n "$update_rc_args" ] ; then
  update-rc.d $update_rc_args
fi


if [ "$1" = "configure" ] || [ "$1" = "abort-upgrade" ]; then
  if [ -x "/etc/init.d/apt-cacher" ]; then
    invoke-rc.d apt-cacher start ||  exit $?
  fi
fi


PS: you might want to take a look at the socket-activation features of 
systemd. You could have systemd-systems be always socket-activated. One 
might even think of removing the standalone daemon mode....

-- 
Saludos