Re: bug - package libtest-json-schema-acceptance-perl

[Andrius Merkys <merkys@debian.org>]

Dear Karen,

On 2021-12-26 02:06, Karen Etheridge wrote:
> I am the maintainer of
> https://metacpan.org/dist/Test-JSON-Schema-Acceptance
> <https://metacpan.org/dist/Test-JSON-Schema-Acceptance> which is
> packaged as libtest-json-schema-acceptance-perl.

Maintainer of libtest-json-schema-acceptance-perl Debian package here.

> I've just noticed that its share/ directory is not being taken from the
> cpan release, but rather copied directly from
> github.com/json-schema-org/JSON-Schema-Test-Suite
> <http://github.com/json-schema-org/JSON-Schema-Test-Suite>.  Please
> don't do that -- the data is not equivalent and downstream consumers may
> fail their tests if the data does not match what was expected in the
> cpan release.

I have done so because of two reasons:

1. To use the same version of JSON Schema Test Suite in all Debian packages;

2. To deduplicate the shipped files.

When I did the packaging I noticed that JSON Schema Test Suite in
Test::JSON::Schema::Acceptance is already a bit newer than the last
release of JSON Schema Test Suite. I understand why this difference matters.

I am fine with undoing my decision to replace files from CPAN release
with ones from JSON Schema Test Suite release, but I would like to
discuss an alternative approach first (including Adam Cecile, the
maintainer of json-schema-test-suite Debian package, in CC). JSON Schema
Test Suite is released quite rarely, albeit its development is quite
intensive. I expect most commits there being additions of new tests not
touching already existing files much. Thus maybe it is better to package
its Git HEAD and update it from time to time instead of sticking to
releases (previous one happened in 2018)?

Karen, would it still be acceptable to have more up-to-date JSON Schema
Test Suite in libtest-json-schema-acceptance-perl's share/ instead of
what is in the CPAN release?

Adam, does packaging Git HEAD of JSON Schema Test Suite make sense to
you? Are you aware of potential breakages to the reverse dependencies?

If my proposal does not seem viable, I can revert my packaging choice. I
am not tied to it very strongly.

Thanks a lot,
Andrius