This is an incomplete dump of things that should have probably been done differently, but might either be too late to fix or change now (barring time travel), might require huge transitions and lots of work, or might be too difficult for little apparent gain. Of course this should not be taken as problems that should or will not be fixed, only that they might require a very brave and persistent soul to get to move it forward!


Detailed explanation at

Multi-Arch file refcounting

The file refcounting is something that dpkg performs for Multi-Arch:same packages, so that shared files between different architecture instances do not need to be split into common packages.

There was a big discussion (FIXME link, and a summary of some of the problems in just before the deployment of the Multi-Arch enabled dpkg in Debian, and the majority of participants deemed the requirements to split packages as too much work, so refcounting got reluctantly reintroduced in the codebase.

But although file refcounting has some nice properties to avoid work for maintainers has also some very nasty ones. Some are even in principle unfixable. In addition backpedaling on that decision would imply quite some work now. The current requirements are:


The currently implemented and proposed workaround to some of this problems has been a series of ad-hoc hacks:



.deb size limit

The ar container has a hard limit on each member size (around 9536.74 MiB). This cannot be fixed without breaking compatibility with the ar format. Possible solutions could be to:

Build profiles


Debian started without build profiles and the philosophy to build source packages with all features enabled. As a result, instead of having positive build profile names (like in Gentoo) which enable features, we must use negative build profile names which disable features. This leads to a double negative for build dependencies that are required to compile a source package with a certain feature:

Build-Depends: foo <!nofoo>

If Debian had the concept of build profiles from the start (in the same way that Gentoo has USE flags) then above could be rewritten into the much more readable and less confusing form:

Build-Depends: foo <foo>

Namespace separator

The package specific namespace separator is «.», but that is a valid character for a package name, so it was not a very good choice. A better separator would have been «/».

Built-Using field

This field was concocted in Debian to track shadow dependencies that are not commonly represented in the usual fields. But its scope was quite reduced to only cover license-required dependencies (such as the ones imposed by some copyleft licenses). Its quite generic name has been a source of confusion, as people have tried to use this same field to also track other related shadow dependencies (that do not stem from license requirements), such as plain static linking dependencies.

There's an upcoming field called Static-Built-Using, that should give a better name to the latter case. But that still leaves the original field with a poor name, where it might have been better named something like say License-Built-Using or similar.