Bug#1091856: libjson-validator-perl: Requires cache symlink for v3.0 schema
Wouter Verhelst
w at uter.be
Sun Feb 1 15:53:32 GMT 2026
On Thu, Jan 02, 2025 at 01:31:13PM +0200, Andrius Merkys wrote:
> Hello,
>
> On 2025-01-01 19:03, gregor herrmann wrote:
> > Control: tag -1 + confirmed
> >
> > On Wed, 01 Jan 2025 17:23:13 +0200, Wouter Verhelst wrote:
> >
> > > Running 'strace -ff -o foo <application>; grep Validator.cache foo*' outputs:
> > >
> > > foo.146500:newfstatat(AT_FDCWD, "/usr/share/perl5/JSON/Validator/cache/a516498b60c53096b2ce2cd83ebe0abc", 0x56545a8b14b8, 0) = -1 ENOENT (No such file or directory)
> > >
> > > Creating a symlink with that name to
> > > '../../../../openapi-specificaction/schemas/v3.0/schema.yaml' resolves the
> > > issue.
> > >
> > > Presumably a symlink for v1.2 and v3.1 should be created too, but I
> > > didn't immediately find out how the hash is computed, so I don't know
> > > which ones to use.
> >
> > Hm, indeed, there's only a symlink for v2.0.
> >
> >
> > The symlinks should be created in d/rules:
> >
> > execute_after_dh_install:
> > find /usr/share/openapi-specification/schemas -name schema.json \
> > | while read SCHEMA; \
> > do jq '.["id"]' $${SCHEMA} | tr -d '"' \
> > | perl -pe 's/#?\n$$//' | md5sum | cut -d ' ' -f 1 \
> > | xargs -i ln -s $${SCHEMA} debian/libjson-validator-perl/usr/share/perl5/JSON/Validator/cache/{}; \
> >
> >
> > In pratice this does not end so well because:
> >
> > # find /usr/share/openapi-specification/schemas -name schema.json
> > /usr/share/openapi-specification/schemas/v2.0/schema.json
> >
> >
> > v3.0 and v3.1 have a schema.yml:
> >
> > # find /usr/share/openapi-specification/ -name schema.yaml
> > /usr/share/openapi-specification/schemas/v3.1/schema.yaml
> > /usr/share/openapi-specification/schemas/v3.0/schema.yaml
> >
> >
> > For v1.2 probably
> > /usr/share/openapi-specification/schemas/v1.2/apiDeclaration.json
> > is the closest thing …
> >
> >
> > Cc'ing Andrius, who also maintains the openapi-specification package.
>
> Hash of a516498b60c53096b2ce2cd83ebe0abc matches schema URL
> https://spec.openapis.org/oas/3.0/schema/2019-04-02 which seems to be a
> pre-release snapshot for v3.0. Wouter's observation that YAML schema of v3.0
> passes instead of JSON is news to me, but this is really good given that
> openapi-specification has switched to releasing their schemas in YAML. Thus
> libjson-validator-perl should probably create cache symlinks for schema.yaml
> files as well.
>
> Now about solving the issue affecting sreview-web. I see the following
> options:
>
> 1. Patch sreview-web to use v3.0 schema instead of its pre-release snapshot
> and include cache symlink for schemas/v3.0/schema.yaml in
> libjson-validator-perl.
So, the issue here is that sreview-web doesn't actually directly use
JSON::Validator; instead, it uses Mojolicious::Plugin::OpenAPI, and
*that* uses JSON::Validator.
The problem is that Mojolicious::Plugin::OpenAPI does not allow you to
select a spec URL. It hardcodes the 2019-04-02 URL, and this cannot be
configured.
(it does allow creating a JSON::Validator::Schema::OpenAPIv3 object that
you can then pass to the validator parameter of
Mojolicious::Plugin::OpenAPI, and that does allow you to specify a spec
URL, but that is ignored. Additionally, it allows you to set a schema
URL to the value "v3", which I tried to set to the correct schema URL,
but similarly, that also does not result in the correct URL being used)
All this means that until this bug is fixed in Debian, effectively,
Mojolicious::Plugin::OpenAPI is completely broken for any application
using OpenAPIv3 specifications (which includes SReview).
> 2. Stop excluding original cached schemas from libjson-validator-perl.
> Unrepacked upstream tarball has JSON schema for
> https://spec.openapis.org/oas/3.0/schema/2019-04-02.
>
> I like the Option 1 better, but I agree that patching sreview-web is not
> nice. Option 2 is painful as well, as we would have to collect the licenses
> of all the cached schemas in the upstream tarball.
As sreview-web is my own code, option 1 should theoretically not be too
hard. But it's just *not possible* to do it at that level (we should be
able to patch Mojolicious::Plugin::OpenAPI though).
As we are able to ship the OpenAPI specifications in the
openapi-specification tarball, however, I just don't see why it's not
possible to ship them in libjson-validator-perl? I mean, sure, the files
in the JSON::Validator tarball don't have licenses attached, but the
licenses exist, we just need to get them from elsewhere -- and since
openapi-specification exists in Debian main, clearly it's free software.
--
w at uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
I will have a Tin-Actinium-Potassium mixture, thanks.
More information about the pkg-perl-maintainers
mailing list