Software updater snuck in a package that is unwanted

[Ralf Mardorf]

On Wed, 18 Oct 2017 00:54:15 +0800 (AWST), Bret Busby wrote:
>The following packages will be REMOVED:
>   ubuntu-mate-core* ubuntu-mate-desktop* unattended-upgrades*

It was already several times explained,that removing so
called meta-packages doesn't remove anything, but a copyright
information and a text with changes to the previous meta packages.

https://packages.ubuntu.com/xenial-updates/amd64/ubuntu-mate-core/filelist
https://packages.ubuntu.com/xenial-updates/amd64/ubuntu-mate-desktop/filelist

"unattended-upgrades" is a hard dependency of the quasi empty
meta-package "ubuntu-mate-core".

"ubuntu-mate-core" is a hard dependency of the quasi empty meta-package
"ubuntu-mate-desktop".

Those meta-packages allow you to install a selection of software, once
you installed this selection of software, you could remove the
meta-packages, without losing any installed software.

https://help.ubuntu.com/community/MetaPackages

https://askubuntu.com/questions/66257/what-is-the-difference-between-a-meta-package-and-a-package

Some information about customizing unattended-upgrades:

https://help.ubuntu.com/lts/serverguide/automatic-updates.html
https://wiki.debian.org/UnattendedUpgrades

Taking a look at the files of the package

[weremouse at moonstudio ~]$ dpkg -L unattended-upgrades | grep systemd
/lib/systemd
/lib/systemd/system
/lib/systemd/system/unattended-upgrades.service

I noticed a systemd unit.

[weremouse at moonstudio ~]$ cat /lib/systemd/system/unattended-upgrades.service
[Unit]
Description=Unattended Upgrades Shutdown
After=network.target local-fs.target
RequiresMountsFor=/var/log /var/run /var/lib /boot
Documentation=man:unattended-upgrade(8)

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStop=/usr/share/unattended-upgrades/unattended-upgrade-shutdown
TimeoutStopSec=900

[Install]
WantedBy=multi-user.target
[weremouse at moonstudio ~]$ systemctl status unattended-upgrades.service
● unattended-upgrades.service - Unattended Upgrades Shutdown
   Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:unattended-upgrade(8)

If something should start the service and you shouldn't find out what,
you could try to mask it.

"Masking: the third level

You may recall that systemd uses several locations to store unit
information. If not, feel free to refer to our previous article on unit
files to refresh your memory. To record unit masking, systemd uses the
local system configuration files in /etc/systemd/. It writes a link
file pointing to /dev/null, the famous “nothing” file in UNIX and
Linux. So for instance, masking httpd.service would result in this link:

$ sudo systemctl mask httpd.service
Created symlink from /etc/systemd/system/httpd.service to /dev/null.

Note this is equivalent to running this command:

$ sudo ln -s /dev/null /etc/systemd/system/httpd.service

Now attempt to start the web server manually:

systemctl start httpd.service

You’ll see the following error message:

Failed to start httpd.service: Unit httpd.service is masked

This is the third level of “off” in systemd. If you boot with a unit
masked, it will not run even to satisfy dependencies. Masking is
powerful for this reason. But like other powerful commands, you should
use it carefully. If you mask an important unit (like the
aforementioned system.slice), you could stop your system from booting
normally. To unmask the unit, use this command:

systemctl unmask httpd.service

Hopefully you can now appreciate even more the power of systemd units
and dependencies.For some additional explanation of masking, refer to
this post from the “systemd for administrators” blog series. See you
soon for our next systemd installment!" -
https://fedoramagazine.org/systemd-masking-units/