Re: Summary: dpkg shared / reference counted files and version match
* Guillem Jover <firstname.lastname@example.org>, 2012-02-10, 23:56:
[ Obviously this “summary” could be considered biased, but I do think
the facts presented are accurate. ]
Well, biased in an euphemism here...
The two reasons for the shared / reference counted files (refcnt from
now on) implementation in dpkg have been:
* To avoid massive package proliferation (due to the mandated copyright
and changelog files), thus the work involved in a one time split and
the size increase in Packages indices.
* To avoid unneeded file duplication, thus wasted space (due to those
mandated files, but also partially just as a consequence of not
splitting files into new arch:all packages, per above).
Personally, I don't consider any of these reasons very important.
* Because this the obvious and elegant way of doing things. It makes
multiarchification easy for packagers, and invisible for uses, including
those users who don't care about multi-arch (unless they rely on paths
to the libraries, which they never should do).
* Deploying refcnt means that M-A:same packages must always be at the
same exact installed version, so that the file contents can match.
More difficult upgrade paths, as this ties the different arch
dependency trees around M-A:same barriers.
By allowing co-installation of two different versions of the same
package, you are opening a can of worms, regardless of whether refcnt is
implemented or not.
* binNMUs need to be performed in lockstep for *all* architectures,
because the installed versions need to match.
Causing useless buildd usage and user downloads for arches not
affected. “Fixing” this by making dpkg treat binNMU versions specially,
besides being just another special case needed for M-A:same packages,
What do you mean by “another”? Yes, MA:same packages needs special
treatment, because they _are_ special.
* binNMUs for the same version cannot be co-installed anyway as their
That could be “fixed” by using the same email address and a hardcoded
date, or not including the binNMU entry at all, or moving that entry to
a new field, etc. All of which seem like ugly hacks, or a possible loss
* Once implemented, this “feature” cannot be taken out, *ever*.
This boils down to “I don't like it”. If it's useful, why would one
consider taking it out?
M-A:same packages cannot have any conflicting files with their foreign
For files in M-A:same packages under a pkgname based path, the pkgname
should always be arch-qualified with the Debian architecture. Most of
these could be handled automatically by debhelper and cdbs, this
includes things like:
This will require changes to the Policy, to which I (and hopefully other
developers) will object.
Please don't throw into the mud work of individual developers (including
me) who already converted their packages to multi-arch. Thank you very