[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Summary: dpkg shared / reference counted files and version match

* Guillem Jover <guillem@debian.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.

How about:
* 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 changelogs differ.
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 of information.


* 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?

Proposed solution

M-A:same packages cannot have any conflicting files with their foreign counterparts. Thus:

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 much.

Jakub Wilk

Reply to: