...

Hi Amano(?), Hans

...

...

Can you make it easier to make an OS package for ConTeXt LMTX by releasing versioned (source) archives, including BUILD/INSTALL instructions in the versioned archives, and so on? I wish I could just extract a versioned binary archive into certain locations or use GNU autotools or use meson build system which is far better than GNU autotools.

there is a github repository for the tex stuff

For reference, the GitHub repository is at:

https://github.com/contextgarden/context-mirror/

It's semi-official mirror, but the authoritative source is the zips hosted by Pragma.

...

and have no experience with all that versioning / release / os packaging stuff (couldn't test it anyway and continuously adapt to teh subtle differences in distributions and os's) ... we just post zips (already for decades) but anyone is free to come up with such instructions (e.g. aditya did some for arch)

anyway, lmtx is still kind of experimental and at some point installation will move to the garden (not much is needed, just a web server) and the packaging scripts are / will be in the distribution .. there are no dependencies (and we keep it that way: self contained bins)

sorry, i just can't spent time on all the possible variant ways of installation .. that is up to volunteers

I think all that Amano is asking for is for older versions of the zips/binaries to be kept available. Right now, the only files available for download that I'm aware of are the latest versions.

This is problematic from a reproducibility standpoint, since if you have multiple people, say, writing a large textbook, it would make sense that they wouldn't want to upgrade their systems constantly in case something breaks. These people can easily just avoid upgrades, but if someone new joins the team, they can only download the newest version. However, that won't necessarily match the older version that everyone else has, which can lead to problems.

Having older versions available would also help in the case of major short-term regressions, since users would be able to (manually) downgrade to an older version if necessary.

An easy solution to this would be the following: instead of overwriting the whole "/install-lmtx/" tree on every update, you would install all the new files to something like "/install-lmtx-2022-08-07/", then have "/install-lmtx/" be a symlink to the latest "/install-lmtx-YYYY-MM-DD/". I don't think that this would be very hard to implement from a technical perspective, and the only downside that I can think of would be extra disk space used. This is a fairly common implementation among other software.

One other solution would be to have "dl.contextgarden.net" mirror a zip/binary combo once every few months or so. These would often be out of date, but they would provide a stable archive that would be useful in cases like this.

This is just a suggestion though; it's not something that I personally need, although I see how it could be potentially valuable for others. At some point binaries won't change much. After all, we don't package

On 8/18/2022 2:51 AM, Max Chernoff wrote: the luatex binaries either and they also can relate to versions of tex code (in the early days of luatex dev we had a similar situation). Now, when it comes to reproducability: the idea behind the relatively small installations is that one just keeps an old tree around. So, say you install, then decide to update but don't want any risk, you then copy the whole tree because there can be engine-texcode depdencies. The current 'installer' actually works liek this: - you download the small zip - using that you install the tree which initially means download and unzip (it uses the build in unzip) - then it makes some symlinks etc a next time you update, it will first check what got changed, for which it uses the hashes in the tma files and that download then doesn't use a zip but an unpacked tree on the server so, in your proposal that would mean that i had to keep around plenty of zips (as each platform has one) as well as all these unpacked trees I now run this on a relatively small virtual machine on one of the servers and don't look forward to expanding that: i can easily push updates there. Of course all can be done, and extending script is easy but one needs a very good reason (to spend spare time and money on this as after all it comes for free). Mojca and I have been discussing the binary part wrt githib but even with the relatively small luametatex binaries it's a bit of a challenge on git. We have some ideas but need time to do it and it doesn't have a high priority. I expect that one of these days the binaries won't change that much. We're still enhancing / improving the math sub-engine so that can create a depedency but at some point there will be a stable version. We do all dev in a separate repository anyway. Also, when the sources are in the distribution users can compile themselves, read: they then could in principle generate the binary for their (updated) platform for an older tree. So .. in due time all will be sorted out. Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------