Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
Hi,
On Tue, 14 Feb 2012, Guillem Jover wrote:
> > * 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.
Why are you so opposed to the refcnt'ing?
It's not such a big deal to maintain this feature in dpkg. And even if the
current implementation is not perfect, it can be improved later when dpkg
will store by itself checksums of provided files.
To me it looks like you don't like refcnt'ing and you're trying to find
some reasons to make it unacceptable.
> It also requires maintainers to carefully consider if the (doc, etc)
> toolchains will generate predictible ouput.
If the maintainer has to install files in non-standard path (because of
the need to arch-qualify it), it will also need maintainers to carefully
consider how to ensure that this move doesn't break anything.
It's not a white/black situation. You're trading one potential problem for
another. And the differing files are likely to be much more easy to spot
than other behaviour changes that might be implied by the move of some
files to arch qualified paths.
> Your proposal still requires papering over the other corner-cases.
Can you be explicit about which corner cases you're referring to ?
> This still does not solve the other issues I listed, namely binNMUs
> have to be performed in lock-step
Can you explain why? If the binnmu changelog is in a arch-specific file,
then we're free to bin-nmu packages separately.
dpkg must just ensure that all "M-A: same" packages have the same source
version (instead of the binary version as currently).
>, more complicated transitions / upgrades.
We have no experience on this. It's a bit early to say whether those
constraints are going to be problematic or not.
> And introduces different solutions for different problems, while my
> proposal is generic for all cases.
There's nothing like a generic solution. You still have to decide whether
you move files to a -common package or if you arch qualify them and keep
them in the M-A: same package. And in both cases, you have to evaluate the
implications, in terms of package installation ordering in one case, in
terms of modifications to do to properly support the arch-qualified files
in the other one.
While it may sound like "cleaner" from a theoretical point of view, I'm
not convinced that it's better than the approach outlined by Russ.
Also you completely ignore the fact that what you're proposing is an
important change for multi-arch packages that have already been converted
both in Debian and in Ubuntu. You're pushing back the work to package
maintainers when there's not reason to not deal with this at the build
infrastructure level.
To reduce some of the downsides associated to compressed files in M-A:
same packages, we could/should investigate how to not compress files
in such packages instead of duplicating them needlessly.
> 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.
This is not a fair characterization of the situation. IMO "Global changes" are
better than "lots of maintainers having to do busy-work splitting their
packages".
You see inconsistency in Russ's proposal but you don't see
inconsistency/incertainty when you change the standard location of
changelog files.
And the "more complicated", it might be true at the dpkg level, but I
don't believe that it's true from the maintainers points of view.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/
Reply to: