Home / server / Questions / 114444
In Process
Mark Renouf
Asked: 2010-02-19 14:23:27 +0800 CST

Debian/Ubuntu: Enabling "dist-upgrade" behavior for unattended-upgrades?

  • 772

We've got a customized distribution of Ubuntu, a repository with some custom packages and we run unattended-upgrades on a number of systems. What we want to be able to do is supply an update of one of our packages which might have a new dependency which is not yet installed.

I understand apt normally prevents that from happening automatically, and using dist-upgrade would permit it.

How can I get that behavior so our unattended upgrades work the same way?

Ideally we'd only want new packages installed if one of our packages causes it to be needed (either as a direct dependency or a child, etc.)

Should I be aware of any potential problems or increased risk of breakage. The systems are generally not easily accessed via the console so anything causing a problem requiring manual intervention would be very bad!

ubuntu debian packages update unattended

3 Answers

  1. As was said, unattended-upgrades apparently doesn't support it, but you can easily get this behavior using cron-apt. cron-apt runs shell code, so you can change its configuration to call dist-upgrade just as you would on the command line.

    • 3

  2. Why not just set up a cron job that runs some variant of apt-get update && apt-get dist-upgrade? Perhaps you mean that you only want the dist-upgrade behavior for one of your packages, but I think it's not worthwhile to address that specially. In a stable release of Ubuntu, dist-upgrade should very rarely pull in new packages, and if it does, there is probably a very good reason for it, such as a security update.

    • 2

  3. Should I be aware of any potential problems or increased risk of breakage.

    After switching to "dist-upgrade", if you use the Ubuntu repos, then I believe you'll start getting kernel updates which you did not before.

    Unfortunately kernel updates are a risk factor in the situation you describe.

    In your situation, it might make sense to a) configure your repo as taking precedence and b) copy the tested kernel from the ubuntu repo into it.

    You can also try to pin / hold the kernel package. The issue I find with this is that different tools respect different pin / hold systems, or none. I.e. apt-get v.s. aptitude v.s. synaptic. Hopefully you would have no need to use synaptic, and you could set pin / holds in both apt-get and aptitude to be safe.

    • 2