My view of Debian's behavior on package upgrades with new dependencies

March 30, 2016

In the primary Reddit discussion of my entry about actually learning apt and dpkg, yentity asked an entirely sensible question:

Why is this [apt-get's --with-new-pkgs] not enabled by default in debian / ubuntu ?

The ultimate answer here is 'because Debian has made a philosophical choice'. Specifically, Debian has decided that no matter what the person building the new version of a Debian package wants or feels is necessary, an 'apt-get upgrade' will never add additional packages to your system. If the builder of the package insists that a new version requires an additional package to be installed, it is better for the upgrade to not happen. Only 'apt-get install <pkg>' (or 'apt-get dist-upgrade') will ever add new packages to your system.

Regardless of what you think about its merits, this is a coherent position for Debian to take. In an anarchic packaging environment with individual Debian developers going their own way, it even has a fair amount of appeal. It certainly means that package maintainers have a strong pragmatic incentive not to add new dependencies, which probably serves to minimize it (which is one reason Debian has apt-get behave this way).

My personal view is that I prefer an environment where package builders are trusted to do the right thing with package dependencies in new versions of their packages, whatever that is. Packages can get new dependencies for all sorts of good reasons, including that what used to be a single package is being split up into several ones. As a sysadmin outsider, I'm not in a good position to second guess the package maintainer on what dependencies are right and whether or not a new one is harmful to my system, so in a trustworthy environment I'll just auto-install new dependencies (as we now do on Ubuntu where it's possible).

(The Debian package format has also made some structural decisions that make things like splitting packages more of a pain. In an RPM-based system, other packages often don't notice or care if you split yours up; in a Debian one, they're more likely to notice.)

It's worth pointing out that this trust fundamentally requires work and politics, in that it requires a policy on 'no unneeded dependencies' (and 'no surprises in package upgrades') and then a group of people who are empowered to judge and enforce the policy (overriding package maintainers when necessary). This sort of control probably does not go well with a relatively anarchic project and it's certainly a point of argument (and one could say that Debian already has enough of those).

Comments on this page:

As an ordinary user (using Ubuntu, but that appears to have the same policy as Debian), the main place I see this is when a kernel upgrade gets pushed to my machine, and for that case I want to not get it pushed automatically. I want to have to do a separate dist-upgrade, so that any time a kernel upgrade is being pushed it gets my attention.

By moschlar at 2016-03-31 12:32:22:

Well, this has also to be seen in the bigger picture, where - within one major release of Debian - a package should simply not undergo such major changes as being split up or introducing new dependencies. Such huge changes should only happen on a new major release of Debian.

By cks at 2016-03-31 19:39:04:

I know that Ubuntu has periodically added new dependencies to packages in LTS releases; for instance, in 14.04 at one point the nfs-common package picked up a dependency on keyutils and python3-tk started requiring the blt package. I assume that one reason these sorts of things can happen is that someone made a mistake in the initial package dependencies and it wasn't noticed in time.

Written on 30 March 2016.
« An awkward confession and what we should do about it
I've now used Python's argparse module and I like it »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Mar 30 01:03:47 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.