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!


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.

| improve this answer | |
  • 2
    First off, unattended-upgrades is already driven by a cron job. See: /etc/cron.daily/apt. What I'd like to know is the proper (cleanest) way to change it's behavior. – Mark Renouf Feb 19 '10 at 22:25
  • 1
    It's not supported. You need to hack it or use something else. – Peter Eisentraut Mar 1 '10 at 0:50

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.

| improve this answer | |

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.