Steve Langasek <vor...@debian.org> writes: > On Wed, Jul 07, 2010 at 05:30:57PM -0700, Russ Allbery wrote: >> Steve Langasek <vor...@debian.org> writes:
>>> OTOH, thinking ahead a little bit, if we *do* insist on requiring >>> changelog entries for binNMUs in the package that may make things >>> interesting for multiarch. Since binNMUS are per-architecture, >>> binNMUS on two architectures may have the same version but different >>> changelog entries, making it impossible to share the /usr/share/doc/ >>> directory between archs for these packages. Maybe the answer there is >>> to have a policy of always binNMUing multiarch packages in lockstep; I >>> don't think the alternative of *requiring* multiarch packages to >>> symlink to an arch: all package for their changelogs makes much >>> sense. >> We could simply require multiarch packages to not symlink their >> /usr/share/doc directory. It's a space optimization only, really, and >> feels like something we can give up if there's a reason to do so. > Sorry, I guess that was a bit obscure for those not closely tracking > multiarch. The issue is that the package for each architecture will > each have its own copy of /usr/share/doc/$pkg/changelog.Debian.gz, and > if those files are *different*, dpkg will not allow installation of more > than one architecture variant of the package. Oh, sorry, now I get it. > 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. > The last would have to be allowed by policy, and implies that for > certain packages, users will effectively never see the binNMU changelog > entry. The business of binary NMUs adding their own changelog entries to the regular changelog feels like a hack to me, and this underscores the reasons why. It introduces another data source for changelog entries that isn't the source package, which is strange and weird and breaks other assumptions. 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). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/871vbeiynb....@windlord.stanford.edu
