The difference between both sources of information is that Homepage is parseable, and debian/copyright is not. DEP-5 will not solve this
problem: the Source field is more or less free-form. It may contain an
URL, but not necessarly, and if there is an URL it is not guaranteed
to be the one to the sources.
When the information is redundant, I would like the Policy to permit
it to be in a single place. This will give a bit of flexibility to
allow for evolutions. I think that the requirement to have the
download URL in the debian/copyright file is one of the reasons why
there is temptation to add other meta-data to it, and I think that it
is not the place for this. Let's remember one of the last sentences of §12.5: ‘You should not use the copyright file as a general README
file’.
I am seeking seconds for the following patch. Given what Julian pointed
out, it only permits Homepage: to be used, not d/watch.
diff --git a/policy/ch-docs.rst b/policy/ch-docs.rst
index dc02bc6..d79f732 100644
--- a/policy/ch-docs.rst
+++ b/policy/ch-docs.rst
@@ -186,8 +186,10 @@ information and distribution license in the file
``/usr/share/doc/package/copyright``. This file must neither be
compressed nor be a symbolic link.
-In addition, the copyright file must say where the upstream sources (if -any) were obtained, and should include a name or contact address for the
+In addition, except in the case where the information would duplicate +exactly the contents of the :ref:`Homepage <s-f-Homepage>` field, the +copyright file must say where the upstream sources (if any) were
+obtained, and should include a name or contact address for the
upstream authors. This can be the name of an individual or an
organization, an email address, a web forum or bugtracker, or any other
means to unambiguously identify who to contact to participate in the
Seconded with or without the following nit.
Minor wording nit: I would put a period after "obtained" and make the next part a separate sentence. ("The copyright file should include a name or contact address for the upstream authors.") Otherwise, it could be read
as saying that the copyright file can only omit the upstream source information if the URL pointed to by Homepage includes name or contact information, but (a) that's not the point of your change, and (b) we want that contact information to always be in the copyright file if available because upstream URLs tend to disappear.
On Sat, Aug 26 2017, Russ Allbery wrote:
Seconded with or without the following nit.
Minor wording nit: I would put a period after "obtained" and make the
next part a separate sentence. ("The copyright file should include a
name or contact address for the upstream authors.") Otherwise, it
could be read as saying that the copyright file can only omit the
upstream source information if the URL pointed to by Homepage includes
name or contact information, but (a) that's not the point of your
change, and (b) we want that contact information to always be in the
copyright file if available because upstream URLs tend to disappear.
I don't think this is so minor!
The paragraph says that the upstream contact information can just be a
URL, and if it is, then I think it could be omitted in favour of the Homepage: field. It was deliberate that my addition applies to both the 'must' and the 'should' requirements.
Do you disagree with this?
Well, it doesn't, exactly... it says that it can be a web forum or bugtracker, but doesn't say anything about being a URL. Hm.
Something about this sits wrong with me, in that I feel like we should capture the upstream contact information directly rather than relying on a URL remaining present on the web. But I'm not sure it's that big of a
deal one way or the other, so I'm still okay with the wording you proposed originally (and still second it).
On Sat, Aug 26 2017, Russ Allbery wrote:
Well, it doesn't, exactly... it says that it can be a web forum or
bugtracker, but doesn't say anything about being a URL. Hm.
Something about this sits wrong with me, in that I feel like we should
capture the upstream contact information directly rather than relying
on a URL remaining present on the web. But I'm not sure it's that big
of a deal one way or the other, so I'm still okay with the wording you
proposed originally (and still second it).
The case I had in mind was where the only information available was a
URI, with no maintainer name or e-mail address. In that case, Homepage: would duplicate that information, and that's what we're trying to avoid
with this bug.
On reflection I realise that such a case is rather unlikely. But I
would still like to cover it with this change.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 68:08:39 |
| Calls: | 6,655 |
| Calls today: | 1 |
| Files: | 12,200 |
| Messages: | 5,332,030 |