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.
http://lists.debian.org/debian-devel/2012/02/msg00316.html
* 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:
/usr/share/doc/pkgname/
/usr/share/bug/pkgname
/usr/share/lintian/overrides/pkgname
/usr/share/mime-info/pkgname.*
/usr/share/menu/pkgname
...
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: