Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Guillem Jover writes ("Re: Multiarch file overlap summary and proposal (was:
> Summary: dpkg shared / reference counted files and version match)"):
>> 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.
Note that splitting files (specifically changelog) into -common package
would require an explicit versioned dependency on the -common package and
produce the same (or similar) lock-step problem for upgrades and
binNMUs. Arch qualifying the files on the other hand would avoid that.
Splitting data files into -common packages will also often need a close
versioned dependency forcing a lock-step of packages. But probably not
so terse that binNMUs would have to be lock-steped.
Overall I think the lock-step being required for reference counted files
won't have such a large effect as you might think.
I think the idea of splitting the binNMU changelog into an extra file is
a great idea as that would allow putting the changelog into -common:all
and depend on the source version and then have the binNMU changelog in
the foo:any package in the symlinked directory. For this to work the
binNMU changelog should be arch and pkg qualified, e.g.
/usr/share/doc/foo-common/Changelog
/usr/share/doc/foo-common/Changelog.binNMU-foo-amd64
/usr/share/doc/foo-common/Changelog.binNMU-bar-i386
/usr/share/doc/foo -> foo-common
/usr/share/doc/bar -> foo-common
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87vcn8rw1z.fsf@frosties.localnet
