Bug#556015: Clarify requirements for copyright file
Steve Langasek <vorlon@debian.org> writes:
> On Wed, Jul 07, 2010 at 05:30:57PM -0700, Russ Allbery wrote:
>> Steve Langasek <vorlon@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 (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: