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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120211001446.gb2...@jwilk.net

Reply via email to