Upgrading packages at jujud startup can interfere with other operations

[Colin Watson]

Last night I began the process of upgrading my laptop from vivid to wily. I edited /etc/apt/sources.list and replaced vivid with wily, ran "apt-get update", and then went off to do some other things while it chewed on the network. Unfortunately one of those other things managed to eat all my memory or otherwise hang my system, and I ended up forcibly rebooting. On restart, I wondered why everything was taking so long, logged in at a virtual console, and found that juju was non-consensually starting a partial upgrade to wily for me! That isn't cool. Here's a contemporaneous snapshot of ps output:

root 2580 0.1 0.2 428756 27016 ? Sl 01:34 0:00 \_ /home/cjwatson/.juju/local/tools/machine-0/jujud machine --data-dir /home/cjwatson/.juju/local --machine-id 0 --debug
root 8731 1.7 0.5 102504 62440 ? S 01:35 0:01 \_ apt-get --option=Dpkg::Options::=--force-confold --option=Dpkg::options::=--force-unsafe-io --assume-yes --quiet install juju-mongodb
root 13279 7.8 0.6 102844 79024 pts/11 Ds+ 01:37 0:00 \_ /usr/bin/dpkg --force-confold --force-unsafe-io --status-fd 89 --unpack --auto-deconfigure /var/cache/apt/archives/lib32gcc1_1%3a5.2.1-22ubuntu2_amd64.deb /var/cache/apt/archives/libx32gcc1_1%3a5.2.1-22ubuntu2_amd64.deb /var/cache/apt/archives/libgcc1_1%3a5.2.1-22ubuntu2_amd64.deb /var/cache/apt/archives/libgcc1_1%3a5.2.1-22ubuntu2_i386.deb /var/cache/apt/archives/libreoffice-calc_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-impress_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-draw_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-gnome_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-gtk_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-writer_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/uno-libs3_5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/ure_5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/python3-uno_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-base-core_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-math_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-style-human_1%3a5.0.2-0ubuntu1_all.deb /var/cache/apt/archives/libreoffice-style-tango_1%3a5.0.2-0ubuntu1_all.deb /var/cache/apt/archives/libreoffice-core_1%3a5.0.2-0ubuntu1_amd64.deb /var/cache/apt/archives/libreoffice-common_1%3a5.0.2-0ubuntu1_all.deb
root 13332 0.0 0.0 17524 2160 pts/11 S+ 01:37 0:00 \_ dpkg-deb --fsys-tarfile /var/cache/apt/archives/libreoffice-calc_1%3a5.0.2-0ubuntu1_amd64.deb
root 13333 0.0 0.0 17516 144 pts/11 S+ 01:37 0:00 \_ dpkg-deb --fsys-tarfile /var/cache/apt/archives/libreoffice-calc_1%3a5.0.2-0ubuntu1_amd64.deb
root 13334 0.0 0.0 25720 2040 pts/11 S+ 01:37 0:00 \_ dpkg-deb --fsys-tarfile /var/cache/apt/archives/libreoffice-calc_1%3a5.0.2-0ubuntu1_amd64.deb

Because juju-mongodb depends on various bits of the C++ stack, in the pathological case where the system is part-way through a distribution upgrade, "apt-get install juju-mongodb" ends up trying to upgrade half the system in the cause of getting to the new version. I ended up killing it so that I could run the upgrade in a more sensibly supervised way.

I can see why jujud wants to ensure that these packages are installed, but it seems unnecessary and a layering violation to upgrade them if they're already installed, and it runs the risk of getting into this kind of situation. Could it please use "apt-get install --no-upgrade" so that it's just doing the former rather than the latter?