Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
Guillem Jover writes ("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:
> > * 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.
I agree that it would be nice to always arch-qualify the changelog
filename. But that would involve a lot of changes to
changelog-reading tools which we perhaps don't want to do right now.
Note that even if we decide to always arch-qualify, we will still have
lots of old packages so all changelog-reading tools will need to look
in both places.
For most changelog-reading tools it won't be very troublesome if they
accidentally don't spot a binNMU entry. So Russ's proposal is a good
step towards your proposal. And if we decide we don't need to go all
the way then it's good enough for now.
> This still does not solve the other issues I listed, namely binNMUs
> have to be performed in lock-step, more complicated transitions /
> upgrades.
I don't think I see where this is coming from. Are you talking about
variation in gzip output ? Given the evidence we've seen here, in
practice I think that is not going to be a problem. Certainly it
won't demand that binNMUs be performed in lock-step.
> 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.
I think the refcounting approach is very worthwhile because it
eliminates unnecessary work (by human maintainers) in many simple
cases.
Ian.
Reply to: