[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#556015: Clarify requirements for copyright file



tags 556015 - patch
quit

Hi,

Russ Allbery wrote:

> Here's a patch that is explicit about the required dependencies and
> discourages the last case.  Does this look good to everyone?

I'm missing some background but hopefully that's all right.  Quick
comments.

> +++ 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 ...

[...]
> -	  <file>/usr/share/doc/<var>package</var>/copyright</file>
> -	  (see <ref id="copyrightfile"> for further details). Also see
> +	  <file>debian/copyright</file> (see <ref id="copyrightfile"> for

Good catch.

[...]
> +	  changelog, <file>/usr/share/doc/<var>package</var></file> may be
> +	  a symbolic link to the documentation directory
> +	  in <file>/usr/share/doc</file> included in another package.
> +	  This may only be done if all of the following requirements are
> +	  met:

The approach here seems very sensible.

[...]
> +	    <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:

		...

> +	      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? [*]

>  	<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 :)

[...]
> +	  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.

[*] 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)?

As currently implemented, these two features (doc/<package> symlink,
binnmu changelog entries) seem to conflict.



Reply to: