Checking versioned dependencies in Debian packages – Take 2
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.
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:
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