Re: Summary: dpkg shared / reference counted files and version match
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
Reply to: