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

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

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


Reply to: