[bug#58140] [PATCH 2/6] gnu: Add kaldi-for-vosk.

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1.1.1: Type: text/plain, Size: 2316 bytes --]



On 29-09-2022 10:20, Nicolas Graves wrote:
> 
>> Trailing #t haven't been required since a long time.
> A big part of the code, and in particular old forms, come from the code
> of the current kaldi package. Should I also change the same code chunks
> for kaldi in an additional patch ?

That would be nice, but not required I'd say.

>> If it's Linux only, you can use the 'supported-systems' field for that,
>> see (gnu packages linux) for examples.
> I don't really know that. Ydotool probably only work on Linux, since
> they rely on linux keycodes. I don't know for X. Maybe someone should
> test. Should I suppose it only supports Linux by default?

I think that usually 'if it works on Linux, it probably can work on 
similar-ish systems as well’ is a reasonable assumption, but perhaps 
with the keycodes, it isn't.

However, if the problem is in 'ydotool', you can mention that in the 
supported-systems of 'ydotool', 'supported-systems' has a kind of 
implicit transitivity going by the use of 
package-transitive-supported-systems in (guix ui).

>> Why select an older version?  Would keeping the original (and more
>> up-to-date) version work?  To avoid a name conflict between the openfst
>> (which would be inconvenient for "guix show", "guix install", "guix
>> shell"), you can override the 'name' field.
> 
> No, it doesn't work and that's the reason why I used this version.

In that case, I recommend adding a comment to the definition, to avoid 
the risk of someone 'helpfully' updating the package anyway, and an 
upstream report, such that upstream can address the compatibility 
problems with the new version.

> It
> might however work with the version that's present for kaldi (1.7.3
> IIRC), I can test that. But the flags aren't the same, so we probably
> should do another package anyway.
> 
> I didn't change the name, but I also haven't exported the variable
> (define instead of define-public). I expected the package to not be
> available through "guix search" or "guix install". Is that OK?

I suppose it is OK, though personally I think it might be a bit 
confusing, e.g. to people using "guix shell -D ..." ending up with a 
package version in their environment that they can't find with "guix 
search".

Greetings,
Maxime.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]