a few questions regarding packaging chez-scheme

[juhp]

I have submitted chez-scheme for package review so that it can be added to Fedora Linux, finally :-)
(see https://bugzilla.redhat.com/show_bug.cgi?id=2281419)

A few questions are coming up:

• (actually first from me) Should it strictly be called chezscheme or is chez-scheme equally valid? (certainly not too late to change now) or even is ChezScheme preferred (Fedora also allows cased package names, so maybe this seems truest to the upstream naming) - not sure which is easier to find..
• Is it useful to include libkernel.a and main.o in the package? (I could only find Why is main.o installed? #811 somewhat discussing this)

My personal motivation for packaging is for Idris2

[juhp]

One more question I have: I noticed that the nanopass and stex submodules are pointing to rather old commits...
Is there any plan to move to newer? Doesn't really block Fedora, so mostly curious

[shenlebantongying]

Should it strictly be called chezscheme or is chez-scheme equally valid?

Idris2

For the case of idris2, the name does not matter because it falls back to all possibilities idris-lang/Idris2@d4553a1

All possible namings exist somewhere. homebrew ->chez, guix -> chez-scheme, debian -> chezscheme.

The root of this list of fallbacks is because chez default to scheme which certainly conflicts with another scheme, and thus everyone renames it slightly different.

Maybe in ChezScheme 11 or now, this scheme should be changed to chez to end this little pointless fragmentation once for all.

ChezScheme/configure

Lines 84 to 86 in fa451a1

	installschemename="scheme"
	installpetitename="petite"
	installscriptname="scheme-script"

[LiberalArtist]

Should it strictly be called chezscheme or is chez-scheme equally valid?

…

All possible namings exist somewhere. homebrew ->chez, guix -> chez-scheme, debian -> chezscheme.

For the package name, I would go with whatever seems most idiomatic for your distro's conventions.

For the name of the binary, does Fedora have something analogous to Debian's alternatives system? (I haven't seriously used an RPM-based distro since c. 2005.) If so, I recommend using that to make scheme and scheme-script available—as does R6RS Appendix D.3.4. Many Chez Scheme users (including me) expect to run it as scheme, but it does conflict with MIT/GNU Scheme and maybe others. I think the alternative name is less important, though personally I like either chez-scheme or chez better than chezscheme. (I would not emulate the Guix packaging on this, though: since before I got involved, our package has created chez-scheme and chez-scheme.boot as symlinks to scheme and scheme.boot, but the way it's implemented doesn't actually fix the conflict in our tooling for scheme …)

Re https://bugzilla.redhat.com/show_bug.cgi?id=2281419#c8:

There is a static library usr/lib64/tarm64le/libkernel.a. Is this needed? If so, how is it used? Could it be made a dynamically linked library?

The static library is used for embedding Chez Scheme into applications, as documented here, among other places. It seems useful to distribute if your distro generally distributes static libraries.

IIUC, Chez Scheme doesn't currently support building something like libchezscheme.so.10.0.0 on Unix-like systems. My distro would prefer that, too: I've thought about looking into it, but I don't know how difficult it would be. For Windows, there is support for csv10.0.0.dll.

I'm less convinced about the usefulness of main.o, as I wrote in #811.

One more question I have: I noticed that the nanopass and stex submodules are pointing to rather old commits... Is there any plan to move to newer? Doesn't really block Fedora, so mostly curious

When #761 is ready it will update stex. (I hope to get back to the helpful comments on dybvig/stex#7 soon!) In Guix, we have been using dybvig/stex@afa6075 (the latest) for some time, plus my patch in dybvig/stex#6 (but note that dybvig/stex#7 includes an improved version).

It looks like there have only been two commits to nanopass since the one pointed to: nanopass/nanopass-framework-scheme@f3100ce just improves an error message, but it does seem like nanopass/nanopass-framework-scheme@1b59636 might be relevant.

On that note, Guix and Debian both package stex. Guix also packages Zuo and shares it between Chez Scheme and Racket.

[juhp]

Thank you @LiberalArtist - this was exactly the kind of reply I was hoping for 🙏

For the package name, I would go with whatever seems most idiomatic for your distro's conventions.

Okay I will probably just stay with "chez-scheme" then - I could provide some package name aliases if appropriate/needed later, thanks.

For the name of the binary, does Fedora have something analogous to Debian's alternatives system? (I haven't seriously used an RPM-based distro since c. 2005.) If so, I recommend using that to make scheme and scheme-script available—as does R6RS Appendix D.3.4. Many Chez Scheme users (including me) expect to run it as scheme, but it does conflict with MIT/GNU Scheme and maybe others.

We do have alternatives in Fedora too, so that could be used.
In a slightly sad state of affairs we don't actually seem to have any other /usr/bin/scheme already in Fedora currently...

Re https://bugzilla.redhat.com/show_bug.cgi?id=2281419#c8:

There is a static library usr/lib64/tarm64le/libkernel.a. Is this needed? If so, how is it used? Could it be made a dynamically linked library?

The static library is used for embedding Chez Scheme into applications, as documented here, among other places. It seems useful to distribute if your distro generally distributes static libraries.

Fedora doesn't generally distribute static libs, so I guess I could pop it into a static subpackage.

I'm less convinced about the usefulness of main.o, as I wrote in #811.

Okay I just wanted to check that it doesn't provide some critical functionality, like an RTS for binaries or something.

Thank you again for the detailed answers.

[juhp]

So probably scheme.h should be subpackaged together with libkernel.a and main.o in a devel subpackage ?

[LiberalArtist]

Some probably scheme.h should be subpackaged together with libkernel.a and main.o in a devel subpackage ?

That's what Debian does, as chezscheme-dev.

If you have a doc subpackage, you may want to consider putting the examples directory there, if you haven't already.