On Fri, Feb 10, 2012 at 11:56:20PM +0100, Guillem Jover wrote: > [ Obviously this “summary” could be considered biased, but I do think > the facts presented are accurate. ] > The two reasons for the shared / reference counted files (refcnt from > now on) implementation in dpkg have been:
Well the bias comes up quite quick when you conveniently omit the MAIN reason right here and rather discuss it at the end of document.. * Because shared files packaging simpler for maintainers. Package profiliation and duplication of arch-independent data are merely effecty that happen when packagers workaround the lack of shared identical files. > * 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). > This has the following implications: > > * 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. > > * 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, > would be wrong, as arch-indep content can actually change between > builds, ex. generated documentation. > > * binNMUs for the same version might not be co-installable because doc > generators, compressors, etc, might not always produce the same output. > ↓ > This is a pretty fragile thing to rely on. New architectures or local > builds might give a hard time if generated output changed in the past. > A possible fix, but only for the compressed files case might be to ship > them uncompresesd, but that counters the desire to reduce wasted space. > > * 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. One solution for the binNMU changelogs and generated docs would be to use arch-qualified paths for those files. That is much more lightweight solution that arch-qualifying all files, even if identical. > Given all the above, I'll be pulling off for now the file refcnt and > version match logic from my pu/multiarch/master branch. If some compelling > arguments are brought up, something I honestly don't really see happening, > then they can be actually reintroduced at any point. > 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 > ... I find the requring arch-qualified path for for arch-independent data ugly system architecture. But of course the beauty of architecture is in the eye of the beholder (and lets not forget that Unix with its worse-is-better philosophy[1] was never intended to be architectural masterpiece). Personally if leaving out shared files makes you upload multiarch enabled dpkg to unstable before sagrada familia is complete, i can live it (cursing silently in my room converting packages to the new requirement...). I can take the trade-off of having something better-than-current soon over having the perfect version in distant future... Riku -- 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/20120211012833.ga21...@afflict.kos.to
