Re: Multiarch file overlap summary and proposal (was: Summary: dpkg shared / reference counted files and version match)
On Tue, 2012-02-14 at 14:28:58 +0000, Ian Jackson wrote:
> 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.
I've never proposed to arch-qualify the filename for the stuff under
/usr/share/doc/pkgname/, I've proposed to arch-qualify the pkgname in
the path (/usr/share/doc/pkgname:arch/), but only for M-A:same packages,
which are the only ones needing the disambiguation. This is how dpkg
handles pkgname output, or how it stores their data in the db too.
And it should be easy to ask a multiarch enabled dpkg-query for example
to normalize the pkgname output to be used on those paths, or otherwise
do it by hand:
if M-A == same
pkgname:arch
else
pkgname
> 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.
How many tools are there that actually read the binary package changelog
file anyway? I only know of packages.d.o. Any other tool reading from
the installed path, cannot really rely on it being present at all
anyway, per policy.
And in addition, binNMU split changelogs are going to be there forever,
and as such their possible double locations. While the possible double
location for M-A:same packages using pkgname:arch qualified pathnames
would only be temporary and disappear once the packages have been rebuilt
with a new debhelper which automatically installs them in the correct
place.
> > 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.
As I mentioned in Riku's reply, the amount of packages that would need
splitting that would otherwise not be needed should be even less than
before (which was predicted at around 700), also as I mentioned there
too, nothing prevents us from arch-qualifying paths (with Debian arch
or multiarch triplet depending on the case) if that's more convenient
or safer (as per your essential data example), and is what we've been
doing anyway for arch-indep data shipped in arch:any packages all along.
Given the amount of hacks or special casing piling up to make refcnt'ing
workable, when all that's really needed is a one time handling (or a
possible additional change for already converted packages, for things
that debhelper might not be able to handle) of moving qualifying paths
or splitting into new packages, it really does not seem worth it, no.
regards,
guillem
Reply to: