Hi Bill,
Am Fri, Jan 28, 2022 at 10:00:36AM +0100 schrieb Bill Allombert:
> On Fri, Jan 28, 2022 at 09:08:17AM +0100, Andreas Tille wrote:
> > > It should be possible to use it with the plain old copyright format too,
> > > otherwise we are kind of renegating on our promise that the machine
> > > readable copyright format be optionnal.
> >
> > Did we ever promised this?
>
> Yes we did.
Any links to refresh my mind?
> > I personally would rather think that excluding files from the upstream
> > source is a pretty good reason to make DEP5 mandatory *for these cases*.
> > Besides a sensible way of documentation it saves maintainer time to
> > simply use uscan to obtain a proper tarball.
>
> The issue is that mk-origtargz does not actually need any field from
> DEP5, it only needs the extra fields it specifies.
I can't parse this. Do you mean `man mk-origtargz` is reading fields
that are not mentioned in DEP5. I'd say DEP5 is just older than
Files-Excluded and the good thing about DEP5 is that it *enabled* other
tools to parse those fields.
> It would be more
> sensible for mk-origtargz to get this information from debian/watch
> or debian/mk-origtargz.
I do not see any need for a new file debian/mk-origtargz for a solved
problem. I also do not think that debian/watch is a good place since it
defined where to get a file from and how to detect a new version. From
my point of view debian/copyright is the perfect place to express what
we need to exclude for copyright reasons.
> While the new copyright format is part of the policy package, it is
> a separate specification and is not intented for package to put
> configuration information there.
The Files-Excluded field is not necessarly configuration information -
it documents in a machine-readable format what is excluded. The
advantage of a machine-readable format is that machines can read it
... which is done by mk-origtargz (and not only by this - also some
UDD gatherers are parsing the licenses).
> From the point of view of binary package, the information is quite often
> meaningless since there is not explanation why a file was removed,
> files that are removed are often regenerated at built time and shipped
> and the file not removed from the source might still not be shipped in
> any binary package generated from it. Important feature removal should
> rather be documented in README.Debian.
I do not see any conflict in mentioning sensible information in
README.Debian in addition to debian/copyright.
> So it is quite sufficient for this data to be in the source package
> only.
Sure - but this is no reason to mention it in d/copyright as well.
> Imagine a large red swirl here.
What I'm actually imagine is that the time I need to write this kind of
mails I could perfectly use to convert 2-3 d/copyright files from old
format to DEP5. And now I'm wondering why I'm not doing so ...
Kind regards
Andreas.
--
http://fam-tille.de
