Hi!

We currently require (with a must) in section §12.5, to add to the
debian/copyright, where the upstream source was obtained from:

  ,---
  In addition, the copyright file must say where the upstream sources
  (if any) were obtained, …
  `---

This means that when using a debian/watch file one has to duplicate
the information in two places, with the possibility of this getting
out-of-sync, etc.

In addition the machine readable debian/copyright format, specifies
the Source field as optional, which could perhaps be interpreted as
contradict what policy says.

IMO, ideally the requirement in policy would be lifted by clarifying
that the information should be provided in *either* debian/copyright
or debian/watch.

The other option would be, I guess, to turn the Source field into a
required one. If that's not desired to be done from the
copyright-format itself (because the format can be considered more
general and there's no need for this requirement from the parsing PoV)
then this requirement could perhaps be added from the policy side.

I just noticed recently I've been creating non-compliant packages for
a while. :/ Once there's a decision either way we could add lintian
tags so that we do not miss this kind of problem.

Thanks,
Guillem

Guillem Jover <guillem@debian.org> writes:

Personally, I usually find they're not the same thing.  debian/watch wants
a very specific technical URL (the path to the download location), whereas
I usually use the Source file to specify a higher-level view of the
project.

That's not an argument against your point that this is duplicative; it's
just that I find Source to more normally duplicate Homepage in
debian/control than duplicate debian/watch.

Anyway, I have also found this an odd fit for debian/copyright if one
views debian/copyright as being for the legally-mandated notices plus
license information for Debian package users.  I suspect that it's a
combination of that Policy text predating both Homepage and uscan.

I'm in favor of dropping this information from debian/copyright and
instead writing some language saying that packages should include this
information in Homepage in debian/control and, if there's a substantial
non-obvious difference between the package home page and how to download
it, put download information in debian/watch.

Hmm, right, that just depends on the upstream project. I guess these
tend to converge in the following way:

  debian/watch → Source: → Homepage:

As in you could have the three being distinct, all the same (well the
URL in debian/watch being extended by the filename part), or two from
each side being equal.
we considered debian/copyright not to be the best place, and planned to
eventually move it elsewhere), as long as it's different from the other
two locations.

So I guess the core of the problem I see is that the Source field is
always required.

Thanks,
Guillem

URL is the same in all three places (Homepage in d/control, Source in
d/copyright, and d/watch). [0]
Not a big deal, especially since we handle this mostly automatically,
but still this triplication (is this a word?) doesn't make too much
sense.

Sounds good to me.


Cheers,
gregor


[0] https://metacpan.org/release/Foo-Bar

Hello,
Source: field and a descriptive homepage into the Homepage: field.

I don't think this is a very strong reason not to drop the Source:
field, since the descriptive homepage will usually have a link to the
git web view.  But I thought I'd note my experience.

Source: field seems appropriate, otherwise it looks a bit like a
stretch?

Just to clarify, I didn't intend to propose drop the field, just for
example to make it optional when the same information is elswhere in
the packaging.

Thanks,
Guillem

Hello,

Well, if the tarballs are an afterthought for upstream (perhaps
automatically generated by git-archive(1) on GitHub's releases page)
then I think it's appropriate.