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.
--
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/20110305055603.GB23327@elie
