Skip to content

Checking versioned dependencies in Debian packages – Take 2

May 8, 2011

One of my last blog suggested a way to systematically clean up versioned dependencies in packages. Given the comments posted thereafter, it’s clear that the one-size-fits-all strategy is ill-advised. Sorry about that.

So, should these versioned dependencies be cleaned up or not ?

Well… It depends. Cleaning up versioned dependencies will hurt people when the package you’re working on may be back-ported to old version of Debian.

In corporate world, upgrading a machine may cost a lot, so you can still find production machine running etch. I would not be surprised to hear about older systems still used in production.

In consumer world (mostly desktop or multimedia), people will mostly run more recent versions of Debian.

All in all, the following elements must be considered before removing old versioned dependencies:

  • Is the package likely to be installed on server ? or is it more targeted to consumer world ?
  • What is the policy of the maintenance group of this package ? For instance, Debian perl group policy is to clean up versioned dependencies older than old-stable.

Unfortunately, there’s no universal strategy.

In case you want to clean up old dependencies, the latest version of Dpkg::Control model for Config::Model will be helpful.

The last version of this models provides a bunch of “meta” Dpkg parameters. These parameters are used to customize the behavior of the Dpkg editor tool to suit your needs (For more details, see Config::Model::models::Debian::Dpkg::Meta). The dependency meta parameters will enable you to tune the behavior of config-edit to your needs.

There are 3 dependency parameters, from the most global to the most specific ones:

  • dependency-filter: your personal general policy
  • group-dependency-filter: the policy of the maintainer group of your package
  • package-dependency-filter: filter policy specified per package

Before applying a cleanup, config-edit will check the policies in the above order. The most specific one will be applied. Ie. the group policy will supersede your personal policy and the package specific policy will override the group policy.

Here’s a screenshot of config-edit GUI invoked on a package:

config-edit with a view on dpkg meta parameters

From the parameters set in the GUI above, you can see that a warning will be raised for :

  • perl package with versioned dependencies older or equals than lenny
  • any other package with versioned dependencies older or equals than etch

Last but not least, if you want to use config-edit without any dependency filtering, just make sure that all these filter parameters are empty. You will still benefits from other features, like warning if a package dependency is unknown, which is useful to catch typos.

All the best

From → Debian, packaging

  1. I’m pleased to see you recognise the problems that removing some versioned dependencies could cause. I still haven’t seen any quantification of the benefit of removing them, though.

  2. On the packager side, there’s some benefit. For instance, debian-perl team has a policy to remove old versioned dependencies. When packaging modules, I often forgot to remove unnecessary versioned dependencies. So I’ve added this feature to Dpkg model to take care of this for me. That’s one less detail for me to worry about when packaging.

Trackbacks & Pingbacks

  1. Checking versioned dependencies in Debian packages – Take 2 | - Your one stop for news about Debian

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: