On 8/18/2022 2:51 AM, Max Chernoff wrote:
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
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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / https://www.ntg.nl/mailman/listinfo/ntg-context
webpage : https://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : https://contextgarden.net
___________________________________________________________________________________
