On Wed, Jul 07, 2010 at 05:51:36PM -0700, Russ Allbery wrote: > > This means that any package tagged multiarch needs special care to > > insure it's actually installable in the face of binNMUs, relative to our > > current practices. Either we stop including binNMU changelog entries in > > the packages altogther (but this is hackish to implement), or we require > > all architectures to be binNMUed in lockstep, or we *do* symlink the > > /usr/share/doc directory to a common arch: all package.
> It's kind of a shame to always have to binNMU all architectures in > lockstep just because of a problem like this. Admittedly, most binNMU > reasons already require that, but every once in a while there's something > that's arch-specific, and making armel rebuild everything because of that > is sort of annoying. OTOH, multiarch packages will be a small minority of packages being binNMUed. I.e., multiarch packages will be mostly shared libraries, which are much more often the trigger for binNMUs than the object of them. But if the consensus is that these packages should still symlink their changelogs to an arch: all package instead to avoid the problem, I don't object. > I'm half-tempted to propose introducing a binary-changelog control > information file in the control area of a binary package that can be used > for binNMUs, although there are a bunch of complications with that (such > as the fact that users looking directly in /usr/share/doc/<package> > wouldn't see the entry and would need to also look in /var/lib/dpkg/info > or wherever we dropped the file in the file system after installation). Well, if it's a choice between having the information available on the system somewhere and *not* having it, I think that's still an improvement in spite of the complications. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
