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

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


Reply to: