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