Bug#556015: Clarify requirements for copyright file
Jonathan Nieder <jrnieder@gmail.com> writes:
> Russ Allbery wrote:
>> +++ b/policy.sgml
>> @@ -573,10 +573,15 @@
>> <heading>Copyright considerations</heading>
>>
>> <p>
>> - Every package must be accompanied by a verbatim copy of its
>> + Every binary package must include a verbatim copy of its
>> copyright information and distribution license in the file
>> - <file>/usr/share/doc/<var>package</var>/copyright</file>
>> - (see <ref id="copyrightfile"> for further details).
>> + <file>/usr/share/doc/<var>package</var>/copyright</file> or
>> + symlink the <file>/usr/share/doc/<var>package</var></file>
>> + directory to a package that does (see <ref id="copyrightfile">
>> + for further details).
> I was tempted to misparse this on first reading as
> Every binary package must include
> - a verbatim copy of its copyright info..., or
> - (a) symlink (to) the /usr/share/doc/<package> directory
> of a package that does (include such a verbatim copy).
> Maybe it would be clearer to go with that structure. For example,
> something like this (imitating wording from later)?
> Every binary package must either include a verbatim copy of
> its copyright information and distribution license in the file
> /usr/share/doc/<package>/copyright or include a symlink named
> /usr/share/doc/<package> that points to the /usr/share/doc
> directory of another package that includes a suitable
> copyright file (see ...
Yeah, I agree that's an improvement.
> [...]
>> + <item>
>> + The packages are the same version (both source and Debian
>> + revision) with the possible exception of binary-only
>> + rebuilds of one of the packages, since otherwise
>> + the <file>changelog.Debian.gz</file> in one of the two
>> + packages would not be the changelog for the latest version.
>> + This requires a dependency that ensures exactly the right
>> + version of the other package be installed. For a dependency
>> + between two binary-dependent packages, use:
> Is this advice meant to be normative? It might be clearer to say:
> ... For example, a dependency between two binary-dependent
> packages can use:
> ...
> A dependency between two architecture-independent packages or
> from an architecture-dependent package to an architecture-
> independent package can use:
I think that's better, thanks.
>> + Putting the symlink in an architecture-independent package
>> + and the documentation directory in an architecture-dependent
>> + package should be avoided if the documentation can be moved
>> + to an architecture-independent package instead, but if
>> + required, a dependency similar to:
>> + <example>
>> +Depends: foo (>= ${source:Version}), foo (<< ${source:Version}+b99)
>> + </example>
>> + can be used.
> Sounds reasonable. But I suppose this is the remaining unresolved
> piece: how can the sysadmin (or anyone) learn the reason for the
> binnmu in this case or the previous case? [*]
Right, this was the reason why I hadn't committed anything yet. We have
to decide whether we're going to prohibit arch:any -> arch:all links
completely to ensure that the binNMU changelog entries are visible. My
inclination is to do so, and hence drop this whole section and just say
that it's not allowed, but this will declare several packages in Debian
buggy.
Now, depending on how you read Policy, they were *already* buggy, since
Policy has always required that packages ship changelog files, and those
packages are in essence not including accurate changelog files. But this
is making that very explicit.
>> <p>
>> - Packages in the <em>contrib</em> or <em>non-free</em> archive
>> - areas should state in the copyright file that the package is not
>> - part of the Debian GNU/Linux distribution and briefly explain
>> - why.
>> + In addition to the copyright and distribution license, the
> In addition to the copyright _information_ and distribution license :)
Agreed, that's better.
> [...]
>> + binary packages, but <file>debian/copyright</file> in the source
>> + package must still contain the copyright and distribution
>> + license for the entirety of the source package.
> I believe there were some comments on how this seems stronger than
> the current policy. That very well might be possible because of the
> typo fixed above.
> Should this be relaxed? I believe ftpmasters would not have trouble
> with copyright information being distributed through
> debian/copyright*
> files (+ maybe even upstream's COPYING), but existing tools to extract
> copyright information from a source package would not cope with that.
I don't think there's much gain in relaxing this, personally. The
controversy about this seems to have died down, and as I understand it the
ftpmasters are still basically asking for this.
Is there any package out there right now that's using separated copyright
files as you describe above, without a combined copyright file that
contains all the details?
> [*] Troubling. I am tempted to suggest inventing a new
> changelog.Debian.<arch>
> file listing only binnmu versions (to cope with multiarch), but what
> happens when /usr/share/doc/<package> is a symlink (especially: what
> happens when multiple arch-any packages symlink to the same arch-all
> package this way)?
Yeah, I don't think there's any good way of handling that.
> As currently implemented, these two features (doc/<package> symlink,
> binnmu changelog entries) seem to conflict.
Yup, they do.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: