Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
On Mon, 2012-02-13 at 22:43:04 -0800, Russ Allbery wrote:
> If this is comprehensive, then I propose the following path forward, which
> is a mix of the various solutions that have been discussed:
> * dpkg re-adds the refcounting implementation for multiarch, but along
> with a Policy requirement that packages that are multiarch must only
> contain files in classes 1 and 2 above.
>
> * All packages that want to be multiarch: same have to move all generated
> documentation into a separate package unless the maintainer has very
> carefully checked that the generated documentation will be byte-for-byte
> identical even across minor updates of the documentation generation
> tools and when run at different times.
If packages have to be split anyway to cope with the other cases, then
the number of new packages which might not be needed otherwise will be
even smaller than the predicted amount, at which point it makes even
less sense to support refcnt'ing.
It also requires maintainers to carefully consider if the (doc, etc)
toolchains will generate predictible ouput.
Your proposal still requires papering over the other corner-cases.
> * Policy prohibits arch-varying data files in multiarch: same packages
> except in arch-qualified paths.
Well, there's no escape from this any way you look at it, regardless of
refcnt'ing or not.
> * The binNMU process is changed to add the binNMU changelog entry to an
> arch-qualified file (changelog.Debian.arch, probably). We need to
> figure out what this means if the package being binNMU'd has a
> /usr/share/doc/<package> symlink to another package, though; it's not
> obvious what to do here.
This requires IMO multitude of hacks when the simplest and obvious
arch-qualified pkgname solves this cleanly, and allows debhelper to
automatically deal with it. And for tools to just change where they
always look for those files in the M-A:same case regardless of the
package being binNMUed or not.
This still does not solve the other issues I listed, namely binNMUs
have to be performed in lock-step, more complicated transitions /
upgrades. And introduces different solutions for different problems,
while my proposal is generic for all cases.
So this is still pretty much unconvincing, and seems like clinging
into the refcnt'ing “solution” while it makes things overall more
complicated, will introduce inconsistency and incertainty to
maintainers, needs way more global changes to keep it going, etc.
What I'd change to my proposal in the summary mail, is that arch-indep
files might be considered for splitting at maintainers discretion,
when it actually seems worth it, in the same way we've handled
splitting arch-indep files from arch:any up to now. So for example a
couple of headers could be kept on the -dev package, or Ian's case on
essential and data files could also be kept on the same lib package,
as long as their paths are arch-qualified either trhough a pkgname:arch
or the multiarch triplet. This would reduce even more the amount of
newly split packages.
regards,
guillem
Reply to: