How to clean up dependencies with version in Debian packages
[ Author note: As you can see in the comments of this post, there are some good reasons against the systematic cleanup idea expressed in this post. So take this with a grain of salt. Instead of altering significantly this post, I’ll follow this up later in another post ]
Hello
Now that Squeeze is out, a lot of cleanup is going in Debian packages.
One of them is getting rid of unnecessary dependencies with minimal versions in packages. I.e. getting rid if unnecessary versions like perl (>= 5.8.1).
Because Lenny was shipped with Perl 5.10, requiring Perl with version greater than 5.8 is not necessary and needlessly loads dependencies resolvers.
In other words, you’re not only doing this cleanup to make your source package lighter, you’re doing it also for your users so that package upgrade go faster.
Anyway, checking these versioned in a real PITA. So I’ve enhanced Dpkg control model in Config::Model to take care of this check.
To check your package, install libconfig-model-perl (from Sid), go in your package directory and run this command:
config-edit -application dpkg -ui none
This command will check your control file, your copyright file and may issue warnings or errors.
Some warnings like the versioned dependencies can be fixed automatically with this command:
config-edit -application dpkg -ui none -apply-fixes -save
Be sure to archive your files before running this command to check what’s been done by -apply-fixes options.
For more information on using config-edit, please read Using config-model wiki page.
All the best
Dominique Dumont's Blog 
Can you quantify the load placed on a dependency resolver by a versioned dependency? Without measurements, this smells of premature oprimisation, and it is an optimisation that slightly lessens the overall utility of the system. While upgrades skipping releases are not supported, that doesn’t mean there cannot be situations where a package from 2 releases or more ago is installed — a common example is placing a package on hold due to bugs in the newer versions.
No, I did not measure the load benefit on the dependency resolver. This is not the main purpose of cleaning up the dependencies but a side effect. Cleaning up the source package is the main objective which has the benefit of encouraging team work in perl-pkg team. As for the situation you mention, I’d like to see concrete example. If some package has such an issue, I will add an exception in the Dependency checker. (just like there’s an exception for debhelper’s version)
I’m wit Joey on this one: if some program depends e.g. on Perl 5.6+, then I’d like to have this fact documented in its package — even if “usually” I’m not expecting to meet less than Perl 5.10 in the distro.
Among other things, this eases back-porting.
Less implicit information (“this is a package for Debian Squeeze — hence Perl 5.10”) and more explicit information, making a distro less of a monolith.
Removing such versioned dependencies where they actually have a background (and aren’t set merely for a transitional purpose) is a bad idea in my opinion. The versioned dependency is there for a reason, and I’ve had often enough troubles with backports because the versioned information isn’t there. And still running old-oldstable in some special environments isn’t that uncommon, it’s not needed to make it more complicated for them.
Also, please keep in mind that derivatives might have a longer life-cycle and thus also would still need those information for proper handling of upgrades.
Said that, perl 5.8 is long gone, it’s neither in lenny which is oldstable now, so at least from that point of view there is not much harm done here. Though, suggesting to do that on a general scale is a bad idea without making people aware of the implications it has. The benefit is very minor, IMHO. I rather doubt the upgrade speed as a net benefit compared to the clear documentation of the requirements.
Thanks for your thoughtful reply.
The main point of this tool is cleaning up old cruft to make package maintenance easier. I hope that nobody will object to the benefits of cleaning up old stuff.
That said, it looks like it’s much harder to agree on a common definition of what is “old enough to be cleaned up”…
Let’s say I tune the dependency checker to keep also version of package still found in oldstable (i.e. Lenny) ? Would this be a reasonable trade-off ?
All the best