Removing squid-deb-proxy-client leaves a stale but active config file, breaking apt

[Marius Gedminas]

If I apt-get remove squid-deb-proxy-client, every apt-get install/update/upgrade operation produces this error message:

    0% [Working]Failed to exec method /usr/share/squid-deb-proxy-client/apt-avahi-discover

The workaround is to apt-get purge squid-deb-proxy-client.

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:

apport-collect 1501217

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

Once done, please change the bug status back to New.

[Marius Gedminas (mgedmin)]

apport-collect says

    Package squid-deb-proxy not installed and no hook available, ignoring

    *** Updating problem report

    No additional information collected.

because of course.

[Marius Gedminas (mgedmin)]

Same output if I do

    sudo apt-get install squid-deb-proxy-client
    apport-collect 1501217

I may have filed it against the wrong package? But

    apt-cache show squid-deb-proxy-client|grep Source
    Source: squid-deb-proxy

so huh? bug in apport?

I'm using Ubuntu 14.04 LTS.

[Rolf Leggewie (r0lf)]

> The workaround is to apt-get purge squid-deb-proxy-client.

That is not a workaround, that is the proper "fix".

Squid-deb-proxy-client is essentially simply a package that installs a configuration snippet /etc/apt/apt.conf.d/30autoproxy so that any call to the network will be proxied to a local proxy iff such a proxy is present. That test is being done in /usr/share/squid-deb-proxy-client/apt-avahi-discover. What happens when you remove the package is that /usr/share/squid-deb-proxy-client/apt-avahi-discover gets removed, but /etc/apt/apt.conf.d/30autoproxy stay around until you purge the package.

In my opinion, this is expected behaviour and this ticket should be closed as invalid.

[Marius Gedminas (mgedmin)]

When Debian packages ship cron files, these usually test -x /usr/bin/programname before executing it, to prevent errors in case the package is removed but not purged. I thought it was required by the Debian policy, but I cannot find wording for it. Maybe it was just a courtesy.

[Robie Basak (racb)]

@Marius,

Sorry, I expected the original bug report to at a minimum tell me what package version and Ubuntu release were affected, which is why I jumped straight away to the standard template response asking for apport-collect, as this would normally fill all of that information in. I didn't notice that you had purged the package, and apport-collect them won't be able to report its installed version, etc. I'm not sure about your failure in comment #3.

@Rolf,

Thanks, that explains this bug. I agree that it's currently expected behaviour, but I do think it's a little buggy that the config file is still active after the package is removed. I wonder if it might be possible for /etc/apt/apt.conf.d/30autoproxy to test for /usr/share/squid-deb-proxy-client/apt-avahi-discover before calling it or something?

Since there might be a little scope for user experience improvement here, I'll leave this open until someone determines if this is possible or not.

[Rolf Leggewie (r0lf)]

> Since there might be a little scope for user experience improvement here, I'll leave this open

I absolutely agree, Robie. I already had my finger on the "Invalid" button but I felt just like you that while this is the way it currently is by design, maybe there is still a way to improve user experience. And thus the ticket remained open for further discussion. At the moment, I am not aware of how a potential improvement along the lines suggested here could be done.

[Marius Gedminas (mgedmin)]

I've some half-formed ideas:

- if apt allows a shell command instead of just an executable name, maybe the config could be

    Acquire::http::ProxyAutoDetect "if [ -x /usr/share/squid-deb-proxy-client/apt-avahi-discover ]; then /usr/share/squid-deb-proxy-client/apt-avahi-discover; fi";

- if apt doesn't use the shell, but allows a command with arguments, and not just an executable name, maybe the config could be

    Acquire::http::ProxyAutoDetect "sh -c 'if [ -x /usr/share/squid-deb-proxy-client/apt-avahi-discover ]; then /usr/share/squid-deb-proxy-client/apt-avahi-discover; fi'";

- if apt is truly restricted to just a single executable name in that parameter, maybe the package could ship a small wrapper script that conditionally runs /apt-avahi-discover if it exists, with the wrapper script placed somewhre in /etc, so it's not removed on purge, e.g.

    Acquire::http::ProxyAutoDetect "/etc/squid-deb-proxy-client/apt-avahi-discover";

with /etc/squid-deb-proxy-client/apt-avahi-discover containing

    # you're not expected to modify this, see LP: #1501217
    if [ -x /usr/share/squid-deb-proxy-client/apt-avahi-discover ]; then
        /usr/share/squid-deb-proxy-client/apt-avahi-discover
    fi

I keep not finding the time to experiment and see if one of the first two ideas would work. I don't like the 3rd option.

[Marius Gedminas (mgedmin)]

Experiments show that

    Acquire::http::ProxyAutoDetect "/bin/sh -c 'true'";

produces this error:

    Failed to exec method /bin/sh -c 'true'

so I'm afraid options 1 and 2 are out :(

[Robie Basak (racb)]

Thank you for trying. It might be a reasonable feature request for apt
to make it possible to call a shell or to provide arguments so that we
can call a shell though, in order to resolve this bug. It would be a
reasonably generic solution.

[Rolf Leggewie (r0lf)]

This was fixed in the latest NMU in Debian.

squid-deb-proxy (0.8.14+nmu2) unstable; urgency=medium

  * Non-maintainer upload.
  * move /etc/apt/conf.d/30autoproxy to under /usr/share/squid-deb-proxy-client
    and make symlink to it, to avoid package fetch failure after removed its
    package (Closes: #867682)

 -- Hideki Yamane <email address hidden> Sat, 16 Mar 2019 15:30:32 +0900